设计 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 实践。我希望 XML 定义 WCF 层，而不是让 WCF 指定我的 SOAP、WSDL 和 XSD，但使用 WCF 生成该层，以免向 WCF 添加任何自定义消息处理。我想遵循最常见的 SOA XML 约定，我相信这些约定可能是所有以小写字母开头的标签 - 我是对的吗？我希望尽可能具有版本兼容性。

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

我知道一系列问题，但我试图触及其核心，并且我不确定将问题分开可以提供足够的背景来获得我正在寻找的答案。

Answer 1

XML 通常倾向于驼峰式。 WSDL 和 XML 模式对元素和属性都使用驼峰命名法，例如查看 句法 和 图式.

为什么 SOAP 定义不同，我不知道，但它对元素使用 PascalCasing，对属性使用 CamelCasing，请检查 这里.

类似地，大多数 WS* 规范（也许全部）对元素和属性使用 PascalCasing，请参阅 这里. 。XML 模式对于它为 XML 定义的类型约定是不可知的。

托马斯·埃尔 写了许多重要的书籍 SOA 包括“面向服务的架构”。在章节中 13 和 15 他提供了典型交易各个部分的 XML 示例。它使用 PascalCasing 在 XML 模式中定义类型和对象成员，这与 C# 的类和属性命名的正常模式很好地匹配。因此 WCF 默认值已经非常符合标准。

关于实际的消息命名，一些约定使用camelCasing，其他约定使用PascalCasing，所以我的偏好是匹配主要语言需求，这在 WCF 大小写是 PascalCasing。和 WCF 默认值与应如何编写请求和响应消息的一些示例相匹配， 这里有一些例子.

因此，现在唯一悬而未决的问题是围绕使用的标准化程度如何的基本问题。 OperationContract, DataContract, ，和/或 MessageContract.

仅当您具有复杂类型（在 XSD 说法）是有道理的，我倾向于认为特里指出的 YAGNI（你不会需要它）是正确的选择，但是 厄尔 似乎建议使用一个过程更加密集的版本，所以我仍然不确定用作我的默认选择的最佳方法（问题的主要部分）。

Answer 2

它总是最好的做法不是有一个经营合同多个参数，总是有一个封装所需的所有参数的类型，这将有助于从长远来看。当您添加了新的可选参数，你现有的客户不会打破。

我在业务整合团队，我们与其他公司相当定期整合，（AT＆T，考克斯，埃克森...），没见过一个Web服务调用了多单参数的详细工作。

Answer 3

我觉得诚实取决于具体的方案。如果你只是简单的交换类型[即字符串]，OperationContract的肯定是可以接受的。

您应该当你想表达的复杂类型，如地址，当你要修改的消息格式和DataContract应该利用使用MessageContract。

Answer 4

YAGNI 想到这里。

我说的不超过做到这一点就变得太花哨着眼于未来。 WCF已经是很好的SOA友好。我说，在一般情况下，坚持以默认的选择要谨慎耦合，直到你有特定需要做一些阐述。