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

Question

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

在较早的ASMX web服务中，我会为每个web服务方法创建一个MethodNameRequest和MethodNameResponse对象。

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

通过阅读WCF以及IExtensibleDataObject、FaultContractAttribute和命名空间的工作原理，我似乎可以恢复到在方法名中使用标准参数(字符串、整数等)，如果服务是版本化的，那么ServiceContract继承可以提供这种版本化。

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

对于WCF版本控制来说，省去请求/响应对象是更理想的想法，这是正确的吗？

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

Answer 1

我不同意放弃请求/响应对象是可行的方法。

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

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

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

我通常将服务契约(操作)放在http://myapp.mydomain/v1这样的名称空间中，消息(请求和响应对象)放在http://myapp.mydomain/v1/messages中。

这种方法的一个缺陷是，如果您在http://myapp.mydomain/v1名称空间中有一个操作，将其称为Submit，那么根据约定/默认，soap对象SubmitRequest和SubmitResponse也将存在于同一名称空间中(我不记得运行时异常是什么，但它让我困惑了一段时间)。解决方法是将消息对象放在另一个名称空间中，如上所述。

Answer 2

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