设计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]
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吗？

我知道很多问题，但我想尽全力，而且不确定将问题分开是否能提供足够的背景信息来获取我要的答案。

Answer 1

最好的做法始终是在操作合同中不要有多个参数，总是有一个包装所有必需参数的类型，从长远来看这将有所帮助。 添加新的可选参数时，现有客户不会中断。

我在一个业务集成团队中工作，在该团队中，我们与其他公司（AT＆T，Cox，Exxon等）进行了相当定期的集成，从未见过使用一个以上参数调用Web服务的情况。

Answer 2

XML通常倾向于驼峰。 WSDL和XML Schema对元素和属性都使用camelCasing，例如，检查语法和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的使用要标准化多少。

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

Answer 3

我认为这实际上取决于情况。 如果您只是交换简单类型[即字符串]，那么OperationContract当然是可以接受的。

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

Answer 4

YAGNI在这里浮现在脑海。

我说不要因为对未来太过幻想而这样做。 WCF已经很好地支持SOA。 我说，一般来说，请遵循默认值，并谨慎考虑耦合，直到您有特定的需要进行详细说明为止。