WCF单点接触

您不需要再次生成代理，您只需确保使用正确的接口版本构建客户机即可。如果您非常小心，只添加方法，而不删除或修改，也可以正常工作。当然，这是一个很大的责任管理。

要使用接口而不是生成客户端代理，请检查我之前的问题:

WCF服务引用生成自己的契约接口，不重用我的

你在这里混淆了一些术语，我想你可能指的是一个已知的缺陷，这个缺陷已经在。net 3.5 SP1中修复了。

重新创建WCF代理过去在运行时是一个昂贵的操作。这在。net 3.5中得到了改进，可以透明地缓存代理对象。

如果你指的是代理的"代码维护"，那么你指的就是在客户端实现一个接口。如果您需要维护接口，那么这就回到了基本SOA。如果您的服务提供访问和尽可能多的信息，假设您的服务将用于您尚未考虑的目的，那么您可能不需要在创建接口后修改接口。你也应该考虑你的升级路径。

Juval Lowy在他的书中对这个问题进行了很好的讨论，这本书有点密集，但里面有一些很好的信息。

一个建议:WCF有大量的特性设计，使你的代码非常简单和优雅。如果你担心维护问题，你可能会被迫写一个接口:

string ServiceMethod(string xml) //returns XML

不要这样做。花时间设计一个良好的可维护接口和一个良好的数据/消息契约。这将使WCF在托管您的服务进行交互时免费提供所有额外的功能。

通用(如非特定的、单一的)接口很难理解和编程。不将单个方法定义为API的原因是客户端不可能理解发生了什么，当您更改该接口的(隐式)API时，您的客户端将以可怕的方式中断，而您在编译时无法检测到。

我接触WCF已经有一段时间了，但是如果您的客户端是内部的(相同的代码库，版本控制和部署方案)，那么重新生成WCF代理非常容易，并且拥有一个"强大"详细的API将使您的生活比通用的简单得多。

这取决于你指的是哪种改变。对服务契约的更改确实代价高昂，不应该发生。服务契约处于(或应该处于)足够高的粒度级别，因此很少发生更改。

更常见的是对服务上公开的类型的更改。这些更改更常见，因此您确实需要以这样一种方式进行更改，以尽可能避免破坏现有的客户端。

有几种方法可以做到这一点，例如使用接口以多态方式公开类型，但最简单的方法是确保对类型的更改添加新的数据成员字段，并使新字段非强制性。如果您可以将更改限制在这些字段，那么这将对现有客户端的影响最小，并使新客户端能够使用新字段。

确实，修改服务契约(接口)还需要客户端使用新发布的WSDL在其末端重新创建代理类，甚至可能需要客户端根据新代理更改其代码。我不认为您可以创建这样一个通用接口，它可以处理合同中进一步的所有更改。合同必须非常仔细地编写，以便它不会经常更改，如果需要更改合同，那么最好使用不同的版本部署服务，以便您的旧客户端仍然可以使用旧版本。