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

Question

我正在设计我的第一个“合适的”WCF 服务，并且正在尝试了解如何最好地处理该服务的版本控制。

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

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

阅读有关 WCF 以及 IExtensibleDataObject、FaultContractAttribute 和 Namespacing 的工作原理后，似乎我可以恢复在我的方法中使用标准参数(字符串、int 等)名称，如果服务有版本控制，则 ServiceContract 继承可以提供此版本控制。

我一直在调查http://msdn.microsoft.com/en-us/library/ms731060.aspx并链接了其中的文章，但我只是在寻找一些澄清。

我认为放弃请求/响应对象对于 WCF 版本控制来说更理想，这种想法是否正确？

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

Answer 1

我不同意放弃请求/响应对象是这样的做法。

使用消息进行编码有明显的好处:

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

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

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

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