WCF ChannelFactory кэширование

Question

Я только что прочитал это great article на WCF ChannelFactory кэширование Wenlong Dong.

Мой вопрос заключается в том, как вы можете фактически доказать, что ChannelFactory фактически кэшируется между вызовами? Я соблюдал правила, касающиеся конструкторов ClientBase. Мы используем следующий перегруженный конструктор на нашем объекте, который наследуется от ClientBase:

ClientBase (конечная точка строкиConfigurationName, EndpointAddress remoteAddress);

В упомянутой выше статье утверждается, что:

Для этих конструкторов, все аргументы (в том числе по умолчанию) находятся в следующем списке:

· InstanceContext callbackInstance

· строка конечная точкаConfigurationName

· EndpointAddress remoteAddress

Пока эти три аргумента такой же, когда ClientBase является построен, можно смело предположить, что то же ChannelFactory можно использовать. К счастью, String и Типы EndpointAddress неизменяемы, i.e., мы можем сделать простое сравнение с , чтобы определить, являются ли два аргумента тем же. Для экземпляра InstanceContext мы можем использоватьсравнение ссылок на объекты. Таким образом, тип EndpointTrait имеет , используемый в качестве ключа кэш MRU.

Чтобы проверить теорию кэша ChannelFactory, мы проверяем Hashcode в конструкторе ClientBase, например. var testHash = RuntimeHelpers.GetHashCode (base.ChannelFactory);

Хеш-значение отличается от вызовов, что заставляет нас думать, что ChannelFactory не кэшируется.

Любые мысли?

С уважением

Myles

Answer 1

я тоже была проблема с этим, я получаю очень быстро производительность при сохранении объекта прокси для нескольких вызовов.

Что мне действительно нужно, так это иметь возможность создавать и использовать прокси каждый звонок, но кэширование и оптимизация происходят за кулисами.

Как и вы, я следовал рекомендациям, предложенным Microsoft, включая перенос моей привязки конфигурации из кода и в файл .config (который я не хотел делать).

Я думаю, что это то, что должно быть обработано Microsoft в архитектуре, это слишком похоже на то, что я ценю качество кода для производительности. Во всяком случае, они должны предоставить нам конструктор, который позволяет кэшировать, не имея присутствия в .config ...

Answer 2

Я знаю, что вопрос немного старый, но нет ответа, и если кто-то один и тот же вопрос:

Из статьи вы упомянули:

Перед внутренним каналом (прозрачной proxy) ClientBase создается , логика кэширования для текущей ClientBase может быть отключена , если доступны другие общедоступные свойства (такие как ChannelFactory, Endpoint, и ClientCredentials).

Какие средства вызова ChannelFactory.GetHashCode() против экземпляра ClientBase<IService> на самом деле вызывает кэш должен быть отключен.