Web服务版本控制 - 在WCF中向服务合同添加操作

Question

在WCF服务中，如果我在客户端（使用服务）完成实现后添加方法作为操作合同会发生什么？现有客户是否必须修改他们的实现，即使他们不使用新的操作合同方法？

编辑：客户是否必须更新他们的代理，即使他们不使用新合同？

Answer 1

不，服务中的新操作合同不会破坏客户端的界面。只要客户端依赖的方法签名保持未受损害，您就可以自由地更改您的界面。这意味着您可以根据需要添加任意数量的新界面成员。

Answer 2

答案取决于你的观点。我说改变合同违反了合同。这就是他们称之为“合同”的原因。

通过添加其他操作来更改服务合同会“中断”客户端，因为它将更改其代理代码。在许多企业环境中，即使现有客户端代码未调用新操作，此类更改也需要QA通过。基本上，通过添加操作，您正在编辑客户端代码。从这个意义上讲，很明显需要质量保证。

当您可以改为创建新的服务合同，并且让不同的服务端点实现它时，无需修改服务合同。您甚至可以让新服务同时实现旧合同和新合同，并共享完全相同的代码以实现旧合同。

我也是老式的类型之一，他们认为你应该为不同的合同使用不同的命名空间。至少在挑剔的意义上，新旧合同是不同的，因此可能相同的名称可能意味着两者之间的不同。这可以通过让旧契约派生自旧契约来减轻，以便旧名称将保留在旧名称空间中，但新名称将位于新名称空间中。

Answer 3

我刚刚针对类似情况实施了解决方案。最初，我刚刚创建了一个扩展当前ServiceContract的新接口，使用 Service Contract Inheritence ，更新端点定义以提供新的派生接口（如建议的in this article）。

对于正在连接的其他.net应用程序来说这很好，那些寻找“旧”界面的应用程序得到了那些，那些寻找“新”的应用程序得到了那个。

问题是我有一个非.net应用程序正在寻找明确的硬编码绑定BasicHttpBinding_IOriginalInterface，但新服务提供BasicHttpBinding_IDerivedInterface。

通过将两个接口与公共ServiceContractName [ServiceContract(Name="IOriginalInterface")]统一起来，这可以解决该问题，正如this article所建议的那样。

Answer 4

如果您担心版本控制，我的建议是遵循契约优先方法：WSDL应该是版本化的，因为它是您向客户公开的WSDL他们想要使用您的服务。在没有您直接控制的情况下让WCF（或任何其他Web服务技术）更改WSDL将迟早会导致您（或您的客户）痛苦。

请参阅WCF - contract-first vs. code-first以及有关工作流程的一些建议。