请求和响应对象以及 WCF 版本控制

Question

我正在设计我的第一个“合适的”WCF 服务，并且正在努力弄清楚如何最好地处理服务的版本控制。

在较旧的 ASMX Web 服务中，我将为每个 Web 服务方法创建一个MethodNameRequest 和 MethodNameResponse 对象。

请求对象实际上只是方法参数中通常包含的内容的 POCO 包装器。响应对象通常可以从具有任何错误信息的基本响应对象继承。

阅读有关 WCF 以及 IExtensibleDataObject、FaultContractAttribute 和 Namespacing 的工作原理的信息，似乎我可以在我的方法名称中恢复使用标准参数（字符串、int 等），如果服务是版本化的，那么ServiceContract 继承可以提供这种版本控制。

我一直在研究 http://msdn.microsoft.com/en-us/library/ms731060.aspx 和其中的链接文章，但我只是想澄清一下。

我是否认为放弃 Request/Response 对象对于 WCF 版本控制更理想？

编辑：我刚刚发现这篇文章建议使用显式请求/响应对象：http://www.dasblonde.net/2006/01/05/VersioningWCFServiceContracts.aspx

Answer 1

我不同意放弃 Request/Response 对象就是这样。

使用消息编码有明显的好处：

• 您可以重复使用它们，从而避免将 5 个整数和 3 个字符串传递给许多不同的方法。
• 属性已命名，因此可以可靠地理解，而通过多个层按值传递的参数可能会混淆，等等。
• 如果您选择，它们可以是适当的对象而不仅仅是数据容器 - 包含私有方法等

但您实际上是在询问版本控制。不要忘记您可以在服务合同中对消息进行版本控制。程序集中的类可以具有相同的名称，前提是它们位于不同的命名空间中（例如v1.Request 和v2.Request），并且它们都可以实现所需的接口或从某些基础对象继承。

它们还需要为您的服务使用者进行版本控制，这可以通过 xml 命名空间来完成；我通常将服务合同（操作）放在 http://myapp.mydomain/v1 之类的命名空间中，将消息（请求和响应对象）放在 http://myapp.mydomain/v1/messages 中。

这种方法的一个问题是，如果您有一个操作，请将其命名为 Submit，在 http://myapp.mydomain/v1 命名空间中，然后按照约定/默认，soap 对象 SubmitRequest 和 SubmitResponse 也将存在于同一命名空间中（我不记得运行时异常是什么，但它让我困惑了一段时间）。解决方法是将消息对象放在我上面描述的另一个命名空间中。

Answer 2

参见"Versioning WCF Services: Part I" 和"Versioning WCF Services: Part II"。