设计SOA WCF Web服务时的最佳做法是什么？

Question

发出的操作合同，如：

[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

[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); 

的一件事是我可以定义IsRequired，顺序和名称。

今天我期望唯一的消费者将是一个WCF客户端。但是，我想尽可能设计合同并遵守SOA实践。我不希望WCF指定我的SOAP，WSDL和XSD，而是希望XML定义WCF层，但使用WCF来生成这个WCF层，以便不向WCF添加任何自定义消息处理。我想遵循最常见的SOA XML约定，我认为这可能是所有以小写字母开头的标签 - 我是对的吗？我想尽可能地容忍版本。

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

我知道一组加载的问题，但我试图去了解它的核心，并且我不确定分离问题是否提供足够的上下文来获得我正在寻找的答案。

Answer 1

XML通常倾向于camelCased。 WSDL和XML架构对元素和属性使用camelCasing，例如查看syntax和schema。

为什么SOAP的定义不同，我不知道，但它使用PascalCasing作为元素，驼峰作为属性，请检查here。

相似，大多数WS*规格（也许都是）使用PascalCasing作为元素和属性，请参阅here。 XML Schema对于它为XML定义的类型的约定是不可知的。

Thomas Erl写了很多关于SOA的重要书籍，包括“面向服务的体系结构”。在章节和他提供了许多典型事务的各个部分的XML的例子。它使用PascalCasing定义了XML Schema中的类型和对象成员，这与C＃的类和属性命名的正常模式很好地匹配。因此WCF默认值已经与标准紧密匹配。

关于实际的消息命名，一些约定使用camelCasing，而其他约定使用PascalCasing，所以我的首选是匹配主语言需求，这在WCF案例中是PascalCasing。并且WCF默认值与请求和响应消息如何写入的一些示例匹配，some examples here。

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

定义DataContract只有当你有一个复杂类型（在XSD的说法）是有道理的，我倾向于认为YAGNI（你是不是要去需要它）由特里指出的是正确的选择，但Erl的似乎提出了一个更加流程密集的版本，所以我仍然不确定最佳方法作为我的默认选择（问题的主要部分）。

Answer 2

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

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

Answer 3

YAGNI想到这里。

我说不要过于乐观地期待未来。 WCF已经很好的SOA友好。我说，一般来说，坚持默认设置，并小心耦合，直到你有特定的需要做一些精心设计。

Answer 4

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

我在一个业务集成团队工作，我们经常与其他公司进行整合，并且从未看到过使用多个参数的Web服务调用。