WCF公开元数据还是让客户端实现接口？

让客户端通过添加对服务的引用（基本上所有内容都是为您生成的）或让客户端实现共享接口并手动编写类代码来使用WCF服务的利/弊是什么

---

谢谢

如果自动生成代码，则存在维护问题。 无论何时更改接口或任何服务器配置，都必须重新生成它

因此，我从不从公开的元数据生成客户机

接口应在一个库中定义。让我们称这个图书馆为MyContractsLib。服务实现应该在一个单独的程序集中（我称之为MyContractsImplementation）。客户端应进入另一个程序集

然后，客户端应使用ChannelFactory创建服务

        var cf = new ChannelFactory<MyContractsLib.MyContract>(this.EndpointName);
        MyContractsLib.MyContract serviceProxy = cf.CreateChannel();

var cf=newchannelfactory（this.EndpointName）；
MyContractsLib.MyContract serviceProxy=cf.CreateChannel（）；

唯一需要保证的情况是，服务由第三方开发，并且您独立编写客户端应用程序

---

如果您有时间和意愿，请参阅深入讨论。

一般来说，如果您不使用代码生成，那么您必须手工编写否则将为您生成的内容

Andrew提到的“维护问题”通过在服务合同更改时简单地使用“更新服务引用”来解决。如果这变得很麻烦，那么创建一个单独的项目来包含所有代理类。然后，您只需要在一个地方使用“更新服务引用”

---

当然，如果服务合同或相关合同以不可比拟的方式更改，那么您的客户机代码将不得不更改。无论您使用哪种技术，这都是正确的。

那么，当接口发生变化而您不使用“添加服务引用”时，您会怎么做？@John:客户端和服务实现应该从同一个文件中读取接口。我将把它添加到我的答案中。因此，当更改不兼容时，您仍然存在相同的问题，并且您必须确保生成系统引用的是包含合同的程序集的正确更新版本，这与维护服务的“当前”实例和使用“更新服务引用”没有太大区别。在任何情况下，您都需要为非.NET客户端部署一个服务实例。@约翰：我特别想到的场景是，契约定义、服务定义和客户端都在同一个解决方案中。如果您链接到在不同解决方案中更新的库，那么我认为这相当于由第三方生成的服务。在这个场景中，客户端和服务是紧密耦合的。我在一个单独的库中自动生成代理类可行吗？生成服务引用时，它会在app.config文件中生成代理类和条目。如果您获得的代理类没有app.config文件条目，您不是只获得了一半的好处吗？（请注意，我提倡你用手做任何事情。）@Andrew:app.config问题对于每个将内容放入app.config的组件都是相同的：你总是必须将库的app.config中的配置项复制到应用程序的app（或web.config）中。总是，看看这个类似的问题。有趣的是，两个人回答的是同一个问题。我认为这两个答案在不同的情况下都是正确的。对于我的特定场景，因为我必须选择一个正确的答案，我将使用WSDL