Silverlight中生成的WCF服务客户端是否重用ChannelFactory？
从 silverlight 调用 WCF 服务时应该使用生成的 WCF 服务客户端（例如 MyServiceClient），还是使用 ChannelFactory（例如 ChannelFactory.Create()）？
其他问题提出了这个问题： WCF/Silverlight：为什么使用 ChannelFactory 而不是 Client？
但是，响应只是说最好重用 ChannelFactory。但如果直接这样做，您将丢失生成的 WCF 服务客户端的所有其他功能（异步事件等）。
是否没有办法让生成的 WCF 服务客户端重新使用 ChannelFactory 本身？
Should one use the generated WCF service client (e.g. MyServiceClient) when invoking a WCF service from silverlight, or instead use the ChannelFactory (e.g. ChannelFactory.Create())?
Other questions have asked this question: WCF/Silverlight: Why use a ChannelFactory instead of a Client?
However, the responses just say it's best to re-use the ChannelFactory. But if this is done directly, you lose all of the other functionality of the generated WCF service client (the async events, etc.)
Is there no way to get the generated WCF service client to re-use the ChannelFactory itself?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
WCF 惨败
START_RANT
即使是 Microsoft 和 WCF 团队也知道
ChannelFactory和Channel以及ClientBase的设计方式和方式由于各种性能问题而被更改是一次真正的惨败。代理的处理确实是一团糟，这一事实足以说明 WCF 的可扩展性背后，我们正在处理一个低效、臃肿且复杂的设计。只是糟糕糟糕糟糕。END_RANT
好的，您可能已经查看了文档，但我假设您无法找到答案 - 正如我一样 - 因为没有简单的答案。但我的发现希望总结了这些要点（您在任何 MS 文档中都找不到以下内容）：
1）我们有
ChannelFactory和IChannel。 ChannelFactory 知道如何与传输进行通信，通道知道如何解释 WCF 方法调用的参数，反之亦然。IChannel是“实现”（或看起来像实现）您的服务接口的接口，而 ChannelFactory 具有通信所需的所有抽象（包括端点、安全性等）。2)
ClientBase只不过是ChannelFactory和IChannel拼凑在一起的。所以很明显，创建一次 ChannelFactory 然后一遍又一遍地创建通道意味着它更高效，但是正如您所猜测的那样，这并不那么容易，因为......3）
ChannelFactory一旦打开，就无法更改。这意味着，如果您使用用户名密码连接到 WCF 服务并且用户名密码发生更改，那么您需要一个新的。这可能看起来不是一个大问题，但在 ASP NET 场景中却成为一个大问题。4)
ChannelFactory和IChannel实际上重用了相同的底层通信通道，因此关闭 ChannelFactory 将使 IChannel 无效。这会导致清理代码和决定谁的责任是关闭连接方面的混乱。5）正如你所见，没有简单的答案。如果您不必在运行时使用用户名/密码或更改配置，请创建并缓存 ChannelFactory，然后只需创建通道。无论如何，
ChannelFactory和IChannel比ClientBase更高效。WCF Fiasco
START_RANT
Even Microsoft and WCF team know that the way
ChannelFactoryandChannelandClientBasewas designed and the way it was changed because of various performance issues was a real fiasco. Just the fact that the disposing of proxy is a real mess is enough to know underneath extensibility of WCF, we are dealing with an inefficent, bloated and convoluted design. Just bad bad bad.END_RANT
OK, you probably have looked at documentation but I assume you have not been able to find your answers - as I did not - since there is no easy answer. But here my findings which hopefully summarises these points (you cannot find below in any MS documentation):
1) We have
ChannelFactoryandIChannel.ChannelFactoryknows how to communicate with the transport and channel knows how to interprete parameters to WCF method calls and Vice Versa.IChannelis the one that "implements" (or looks like implementing) your service interface while ChannelFactory has all necessary abstractions for communicating (including endpoint, security, ...).2)
ClientBaseis nothing but bothChannelFactoryandIChannelcobbled together. So it is obvious that creating ChannelFactory once and then creating channels over and over means it is more efficient, howevere as you guessed it is not that easy because ...3)
ChannelFactoryonce opened, cannot be changed. This means that if you use username password to connect to WCF service and that username password changes, then you need a new one. This might not seems like a big problem but it becomes a big problem in an ASP NET scenario.4)
ChannelFactoryandIChannelin fact reuse the same underlying communication channels so closing ChannelFactory will make IChannel invalid. This causes confusion in clean up code and decising whose responsiblity is it to close the connection.5) As you see there is no easy answer. If you do not have to use username/password or change configuration at runtime, create and cache ChannelFactory and then just create the channels. In any case
ChannelFactoryandIChannelis more efficient thanClientBase.