WCF ChannelFactory 与生成代理 [英] WCF ChannelFactory vs generating proxy
问题描述
只是想知道在什么情况下，当您可以使用 ChannelFactory 调用调用时，您更愿意从 WCF 服务生成代理吗?
Just wondering under what circumstances would you prefer to generate a proxy from a WCF service when you can just invoke calls using the ChannelFactory?
这样您就不必生成代理，也不必担心服务器更新时重新生成代理?
This way you won't have to generate a proxy and worry about regenerating a proxy when the server is updated?
谢谢
推荐答案
创建 WCF 客户端有 3 种基本方法:
There are 3 basic ways to create a WCF client:
让 Visual Studio 生成您的代理.此自动生成通过读取 WSDL 连接到服务的代码.如果服务因任何原因发生变化，您必须重新生成它.这样做的最大优点是易于设置 - VS 有一个向导，而且都是自动的.缺点是您依赖 VS 为您完成所有繁重的工作，因此您会失去控制.
Let Visual Studio generate your proxy. This auto generates code that connects to the service by reading the WSDL. If the service changes for any reason you have to regenerate it. The big advantage of this is that it is easy to set up - VS has a wizard and it's all automatic. The disadvantage is that you're relying on VS to do all the hard work for you, and so you lose control.
使用具有已知接口的 ChannelFactory.这依赖于您拥有描述服务(服务合同)的本地接口.最大的优点是可以更轻松地管理更改 - 您仍然需要重新编译和修复更改，但现在您不是重新生成代码，而是引用新接口.通常，当您同时控制服务器和客户端时会使用它，因为它们都可以更容易地模拟以进行单元测试.但是，可以为任何服务编写接口，甚至是 REST 服务 - 请查看此 Twitter API.
Use ChannelFactory with a known interface. This relies on you having local interfaces that describe the service (the service contract). The big advantage is that can manage change much more easily - you still have to recompile and fix changes, but now you're not regenerating code, you're referencing the new interfaces. Commonly this is used when you control both server and client as both can be much more easily mocked for unit testing. However the interfaces can be written for any service, even REST ones - take a look at this Twitter API.
编写您自己的代理 - 这很容易做到，尤其是对于 REST 服务，使用 HttpClient 或 WebClient.这为您提供了最精细的粒度控制，但代价是大量服务 API 处于字符串中.例如: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - 如果 API 的细节改变你不会遇到运行时出错.
Write your own proxy - this is fairly easy to do, especially for REST services, using the HttpClient or WebClient. This gives you the most fine grain control, but at the cost of lots of service API being in strings. For instance: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - if the details of the API change you won't encounter an error until runtime.
就我个人而言，我从不喜欢选项 1 - 依赖自动生成的代码很混乱并且失去太多控制.此外，它经常会产生序列化问题 - 我最终会得到两个相同的类(一个在服务器代码中，一个自动生成)，这些类可以调整但很痛苦.
Personally I've never liked option 1 - relying on the auto generated code is messy and loses too much control. Plus it often creates serialisation issues - I end up with two identical classes (one in the server code, one auto generated) which can be tided up but is a pain.
选项 2 应该是完美的，但是 Channels 有点过于局限了 - 例如它们 完全丢失HTTP错误内容.也就是说，拥有描述服务的接口更容易编码和维护.
Option 2 should be perfect, but Channels are a little too limiting - for instance they completely lose the content of HTTP errors. That said having interfaces that describe the service is much easier to code with and maintain.
这篇关于WCF ChannelFactory 与生成代理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
