ChannelFactory重用策略
我一直在读到 ChannelFactory 的创建是昂贵的，除非有技术原因不这样做，否则应该在可能的情况下重用 ChannelFactory，或者通过某种方式缓存它们，或者使用工厂的静态实例。
根据您的经验，您发现哪些 ChannelFactory 重用策略在 ASP.NET 应用程序上下文中最有用且最强大？
I've been reading that ChannelFactory creation is expensive and that unless there is a technical reason not to, one should reuse ChannelFactories when possible either by caching them someway, or by using static instances of the factories.
In your experience, what ChannelFactory reuse strategies have you found to be the most useful and robust within the context of an ASP.NET application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您使用的是 .NET 3.0 SP1 及更高版本，并且不需要需要直接处理通道的特殊内容，那么最好的选择是仅使用从 ClientBase派生的客户端代理类。 （就像导入服务时生成的那样）。 那些已经在下面缓存了工厂。 请参阅 此处了解详细信息。
如果没有，那么是的，您需要将 IChannelFactory粘贴到 某个地方的对象，但您仍然需要确保适当地处理共享（我认为堆栈不能保证工厂的访问是线程安全的），但除此之外，它应该相当简单。
If you're using .NET 3.0 SP1 and up and don't need special stuff that requires handling channels directly, then the best option would be to just use client-side proxy classes derived from ClientBase<T> (like the ones generated when importing services). Those already cache the factory underneath. See here for the details.
If not, then yeah, you'll need to stick the IChannelFactory<T> object somewhere, but you need to still make sure you handle sharing appropriately (I don't think there's any guarantees made by the stack that access of a factory is thread-safe), but other than that, it should be fairly straight-forward.
Darin Damitrov 在此处发布了有关通道工厂重用的有用答案：-
创建 WCF ChannelFactory
I我最近一直在研究我最近开发的应用程序中的内存使用情况和性能。 我应用了他提倡的技术（使用字典来存储一组通道工厂）并获得了良好的性能提升。
我发现实例化 ChannelFactory 可能需要长达 70 毫秒的时间。 如果这种情况发生很多，它就会迅速增加。
目前，我很谨慎，还没有设置我的 DI 容器来在应用程序的生命周期内提供通道工厂的相同实例。 相反，我让它们在单个 HTTP 请求的持续时间内有效（在此期间可能会进行许多后端服务调用）。
Darin Damitrov posted a useful answer around re-use of channelfactories here:-
creating WCF ChannelFactory<T>
I've been looking at memory usage and performance in an application I've been working on recently. I applied the technique he advocated (using a dictionary to store a set of channelfactories) and had a good performance bump with it.
What I was seeing was that instantiating a channelfactory could take up to 70ms. If this is happening a lot it adds up quickly.
Currently, I'm being cautious and have not set up my DI container to serve up the same instances of the channelfactories for the lifetime of the application. Instead, I make them live for the duration of a single HTTP request (within which there may be many back-end service calls made).