请求和响应对象以及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个字符串和3个字符串传递给许多不同的方法。
• 属性已命名，因此可以可靠地理解，而通过多个层传递的参数可能会混淆，等等。
• 如果您选择 - 它们可以是正确的对象而不仅仅是数据容器 - 包含私有方法等

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

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

使用这种方法的一个问题是，如果你有一个操作，在Submit命名空间中调用它http://myapp.mydomain/v1，那么按惯例/默认为soap对象SubmitRequest和{{1}也将存在于同一名称空间中（我不记得运行时异常是什么，但它让我困惑了一段时间）。解决方案是将消息对象放在另一个名称空间中，如上所述。

Answer 2

请参阅"Versioning WCF Services: Part I"和"Versioning WCF Services: Part II"。