11

给定一个运营合同，例如：

[OperationContract]
void Operation(string param1, string param2, int param3);

这可以重新设计为：

[MessageContract]
public class OperationRequest
{
    [MessageBodyMember]
    public string Param1 { get; set; }

    [MessageBodyMember]
    public string Param2 { get; set; }

    [MessageBodyMember]
    public int Param3 { get; set; }
}

[MessageContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

我喜欢 MessageContract 的一件事是我可以更明确地控制 SOAP 消息的格式。

同样，我可以编写几乎相同的代码，但使用 DataContract：

[DataContract]
public class OperationRequest
{
    [DataMember]
    public string Param1 { get; set; }

    [DataMember]
    public string Param2 { get; set; }

    [DataMember]
    public int Param3 { get; set; }
}

[DataContract]
public class OperationResponse
{
}

[OperationContract]
OperationResponse Operation(OperationRequest request);

我喜欢 DataContract 的一件事是我可以定义 IsRequired、Order 和 Name。

今天，我预计唯一的消费者将是 WCF 客户端。但是，我想先设计契约，并尽可能地坚持 SOA 实践。我不想让 WCF 规定我的 SOAP、WSDL 和 XSD，而是希望 XML 定义 WCF 层，但使用 WCF 生成它，以免向 WCF 添加任何自定义消息处理。我想遵循最常见的 SOA XML 约定，我认为这些约定可能所有标签都以小写开头——对吗？我想尽可能地容忍版本。

总是像这样创建请求和响应消息是否明智？三种格式中的哪一种促进了最佳 SOA 实践？我是否应该更进一步并定义一个 DataContract 和一个 MessageContract，而 MessageContract 只包含 DataContract？或者，如果我真正公开一种新类型（即不将消息类型创建为容器），我是否应该只使用 DataContracts？

我知道一组加载的问题，但我正试图深入其中，我不确定将问题分开是否能提供足够的上下文来获得我正在寻找的答案。

4

4 回答 4

15

在操作合同中不要有多个参数始终是最佳实践，始终具有包装所有必需参数的类型，从长远来看，这将有所帮助。当您添加新的可选参数时，您现有的客户端不会中断。

我在一个业务集成团队工作，我们定期与其他公司（AT&T、Cox、Exxon ...）进行集成，并且从未见过需要多个参数的 Web 服务调用。

于 2009-06-26T05:47:30.313 回答
6

XML通常倾向于驼峰式。WSDL和XMLSchema 对元素和属性都使用 camelCasing，例如检查syntax和schema。

为什么SOAP定义不同，我不知道，但它对元素使用 PascalCasing，对属性使用 camelCasing，请查看此处。

同样，大多数WS*规范（可能全部）使用 PascalCasing 来表示元素和属性，请参见此处。XML Schema 不知道它为 XML 定义的类型的约定。

Thomas Erl撰写了许多重要的书籍，SOA包括“面向服务的架构”。在第13章和第15章中，他提供了一些典型事务各个部分的 XML 示例。它使用 PascalCasing 在 XML Schema 中定义类型和对象成员，这很好地匹配了 C# 中用于类和属性命名的常规模式。因此，WCF默认值已经与标准非常接近。

关于实际的消息命名，一些约定使用 camelCasing 而其他约定使用 PascalCasing，所以我的偏好是匹配主要语言需求，在这种WCF情况下是 PascalCasing。并且WCF默认值匹配请求和响应消息应该如何编写的一些示例，这里有一些示例。

OperationContract所以现在唯一悬而未决的问题是围绕,DataContract和/或的使用标准化多少的基本问题MessageContract。

仅当您具有复杂类型（用XSD说法）才有意义时才定义 DataContract，我倾向于认为 Terry 指出的 YAGNI（您不需要它）是正确的选择，但Erl似乎建议更多处理密集型版本，所以我仍然不确定用作我的默认选择的最佳方法（问题的主要部分）。

于 2009-02-01T23:50:51.067 回答
0

老实说，我认为这取决于场景。如果您只是交换简单类型 [即字符串]，那么 OperationContract 肯定是可以接受的。

当您想要修改消息格式时应该使用 MessageContract，而当您想要表达复杂类型（例如地址）时应该利用 DataContract。

于 2009-01-26T01:36:08.587 回答
0

这里想到了 YAGNI 。

我说不要过分幻想未来。WCF 已经很好地支持 SOA。我说，一般来说，坚持默认值并小心耦合，直到你有特殊需要做一些复杂的事情。

于 2009-01-26T03:34:56.660 回答