WCF客户端代理初始化
我正在使用 WCF 服务并使用 VS 2008 服务引用创建其代理。
我正在寻找调用 WCF 服务方法的最佳模式
- 是否应该在每次调用服务方法时创建客户端代理实例并在完成后立即关闭客户端?当我分析我的客户端应用程序时,我可以看到在初始化代理客户端时获取通道需要花费大量时间
- 我是否应该为客户端代理使用单例模式,以便我可以只使用一次实例并摆脱重新初始化开销?这种做法有什么隐藏的问题吗?
我使用的是 .Net Framework 3.5 SP1,basicHttp
绑定,几乎没有自定义。
I am consuming a WCF service and created its proxy using the VS 2008 service reference.
I am looking for the best pattern to call WCF service method
- Should I create the client proxy instance every time I call the service method and close the client as soon as I am done with that? When I profiled my client application, I could see that it is taking a lot of time to get the Channel while initializing the proxy client
- Should I use a Singleton pattern for the client proxy so that I can use the only once instance and get rid of the re-initializing overhead? Is there any hidden problem with this approach?
I am using the .Net framework 3.5 SP1, basicHttp
binding with little customization.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这取决于;-)
如果您的应用程序中有一个序列需要一个接一个的多次调用,您可以挂在代理客户端上并继续使用它来进行进一步的调用。但请注意检查“故障”状态 - 如果服务器上发生错误,客户端代理和服务器之间的通道可能会“故障”,从而您的客户端代理变得不可用。
另外 - 昂贵的部分是创建
ChannelFactory
- 当您在代码中创建客户端代理时,您可以尝试将这两个步骤分开:保留该通道工厂,例如缓存它第二步
在时间和马力方面应该要少得多:
您可以在每次调用(或调用序列)之前执行此步骤,并且实际上不会从中获得糟糕的性能。
我强烈建议尽可能避免单例 - 这就像打开一罐蠕虫,除非绝对、确实必须(例如,管理一次仅可供一个调用者使用的单个资源的访问),否则不要这样做。
马克
It depends ;-)
If you have a sequence in your app that requires several calls after one another, you could hang on to the proxy client and keep using it to make further calls. Be warned though to check for the "faulted" state - if an error happens on the server, the channel between the client proxy and the server might "fault" and thus your client proxy becomes unusable.
Also - the expensive part is the creation of the
ChannelFactory<T>
- you could try to separate these two steps out when you create your client proyx in code:Hang on to that channel factory, e.g. cache it somewhere
The second step should be much less intensive in terms of time and horsepower:
You could do this step before every call (or call sequence) and shouldn't get bad performance out of that, really.
I would strongly recommend to avoid singletons whenever possible - it's like opening a can of worms, don't do it unless you absolutely, positively have to (e.g. to manage access to a single resource that's only available for one caller at a time).
Marc
很抱歉提出一个老问题,但我想添加这个以方便参考。
我完全同意 marc_s 和 Rally25rs 的观点。因此,从这里开始,但也要考虑使用处理故障状态的代理或包装器。 这是一个关于SO的问题,讨论了一些解决方案,这是另一个 我在互联网上发现了 Corneliu 的一个很好的解决方案,“构建可重用的 ClientBase 代理”。他的解决方案生成包装器,公开您的服务方法,以实现最大的便利性和性能。我仍然需要测试它是否有效:)。
Sorry for kicking up an old question, but I wanted to add this for easy reference.
I fully agree with marc_s and rally25rs. So start there, but also consider using a proxy or wrapper that handles faulted states. Here is a question on SO that discusses some solutions, and here is another good solution I came across on the internet by Corneliu, "Building a reusable ClientBase proxy". His solution generates wrappers that expose your service methods for maximum convenience and performance. I still have to test if it works though :).