在WCF服务中，如果在客户端（使用服务的客户端）完成实现后添加了方法作为操作合同，会发生什么情况？即使他们不使用新的操作契约方法，现有客户端是否必须修改他们的实现？编辑：即使客户端不使用新合同，他们是否必须更新代理？
4个回答
6
不会的，服务中的新操作契约不会破坏客户端的接口。只要客户端依赖的方法签名保持不变，您就可以自由更改接口。这意味着您可以添加任意数量的新接口成员。
- Andrew Hare
4
我刚刚实现了一个类似的解决方案。最初，我创建了一个新接口来扩展当前的ServiceContract，使用“服务契约继承”，更新端点定义以提供新派生接口 (如本文所建议的)。
对于连接的其他.Net应用程序来说这是好的，那些寻找“旧”接口的应用程序得到了它，而那些寻找“新”的应用程序则获得了新接口。
问题在于，我有一个非.NET应用程序，它正在寻找一个明确硬编码的绑定，“BasicHttpBinding_IOriginalInterface”，但新服务却提供了“BasicHttpBinding_IDerivedInterface”。
通过使用共同的ServiceContractName [ServiceContract(Name="IOriginalInterface")] 统一两个接口，解决了这个问题，正如本文所推荐的。
- Unsliced
4
这取决于您的观点。我认为任何形式的更改都违反了合同。这就是为什么它们被称为“合同”。
通过添加其他操作来更改服务合同会“破坏”客户端，因为它将更改其代理代码。在许多企业环境中，即使现有的客户端代码没有调用新操作，这种更改也需要进行QA测试。基本上，通过添加操作，您正在编辑客户端代码。从这个意义上说，很明显需要进行QA测试。
当您可以创建一个新的服务合同并有不同的服务端点实现它时，就无需修改服务合同。您甚至可以让新服务同时实现旧合同和新合同，并使用完全相同的代码来实现旧合同。
我也是那种认为应该为不同合同使用不同命名空间的老派人士之一。在至少挑剔的意义上，旧合同和新合同是不同的，因此相同的名称可能在两者之间意味着不同的含义。这可以通过让新合同派生自旧合同来缓解，以便旧名称将保留在旧命名空间中，而新名称将位于新命名空间中。
通过添加其他操作来更改服务合同会“破坏”客户端，因为它将更改其代理代码。在许多企业环境中，即使现有的客户端代码没有调用新操作，这种更改也需要进行QA测试。基本上，通过添加操作，您正在编辑客户端代码。从这个意义上说，很明显需要进行QA测试。
当您可以创建一个新的服务合同并有不同的服务端点实现它时，就无需修改服务合同。您甚至可以让新服务同时实现旧合同和新合同，并使用完全相同的代码来实现旧合同。
我也是那种认为应该为不同合同使用不同命名空间的老派人士之一。在至少挑剔的意义上，旧合同和新合同是不同的，因此相同的名称可能在两者之间意味着不同的含义。这可以通过让新合同派生自旧合同来缓解，以便旧名称将保留在旧命名空间中，而新名称将位于新命名空间中。
- John Saunders
3
如果我要创建另一个服务契约来容纳新方法，我将无法提供一个统一的接口，将相关方法组合在一起。 - Developer
@John Saunders：我同意你的观点，但从实用的角度来看，我相信你可以看到将新方法放入合同并将其视为向后兼容的新版本的好处。话虽如此，我完全同意你所说的一切，所以给你点赞。 - Andrew Hare
@Nick：一个单一的服务可以实现多个服务契约。如果他们更新了代理，那该怎么办呢？这会给你带来麻烦吗？ - John Saunders
0
如果您关心版本控制，我的建议是采用契约优先的方法：WSDL 应该是需要进行版本控制的，因为当客户想要使用您的服务时，他们所暴露的就是 WSDL。让 WCF（或任何其他 Web 服务技术）在没有您直接控制的情况下更改 WSDL，迟早会给您（或您的客户）带来痛苦。
请参见WCF - contract-first vs. code-first以及一些工作流建议。
- Igor Brejc
2
@Igor：这不是WCF的问题，因为服务契约、操作、数据、故障和消息契约与WSDL几乎是一对一的。这不像ASMX服务，它试图解释你的意思，然后从中创建WSDL。 - John Saunders
@John：没错，但是WSDL仍然是客户端和服务器之间的有效合同，而不是C＃/Java/...客户端/服务器代码，因此应该“尊重”处理。 - Igor Brejc
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接