WCF ChannelFactory缓存

Question

我刚刚阅读了董文龙在WCF ChannelFactory缓存上的这个ChannelFactory。

我的问题是，您如何才能实际证明ChannelFactory实际上是在调用之间缓存的呢？我遵循了关于ClientBase构造函数的规则。我们在从ClientBase继承的对象上使用以下重载构造函数：

ClientBase(string endpointConfigurationName，EndpointAddress remoteAddress)；

在上述条款中指出：

对于这些构造函数，所有参数(包括默认参数)都在以下列表中： ·InstanceContext callbackInstance ·字符串endpointConfigurationName ·EndpointAddress remoteAddress 只要在构造ClientBase时这三个参数是相同的，我们就可以安全地假设可以使用相同的ChannelFactory。幸运的是，字符串和EndpointAddress类型是不可变的，也就是说，我们可以进行简单的比较，以确定两个参数是否相同。对于InstanceContext，我们可以使用对象引用比较。因此，EndpointTrait类型被用作MRU缓存的键。

为了测试ChannelFactory缓存理论，我们正在检查ClientBase构造函数中的哈希代码，例如var testHash =ClientBase

哈希值在调用之间是不同的，这使我们认为ChannelFactory实际上不是缓存的。

有什么想法吗？

问候

迈尔斯

Answer 1

我知道这个问题有点老，但没有答案，如果有人有同样的问题：

从你提到的那篇文章来看：

在创建ClientBase的内部通道(透明代理)之前，如果访问其他公共属性(如ChannelFactory、端点和ClientCredentials)，则可以禁用当前ClientBase的缓存逻辑。

这意味着对ChannelFactory.GetHashCode()实例调用ClientBase<IService>实际上会导致缓存被禁用。

Answer 2

我对此也有一个问题，当我将代理对象保存为多个调用时，我获得了非常快的性能。

我真正想要的是能够在每个调用中创建和使用代理，但是缓存和优化会在幕后进行。

和您一样，我遵循了微软提出的指导方针，包括将绑定配置从代码中移出并放入.config文件(我不想这么做)。

我认为这是微软应该在架构中处理的事情，我觉得这太像在用代码质量来换取性能。如果有的话，他们应该为我们提供一个构造函数，允许缓存而不存在于.config中.