Я читал много статей WCF в Интернете, и похоже, что большинство людей кэшируют объекты ChannelFactory, но не сами каналы. Похоже, что большинство людей боятся использовать кеширование каналов, потому что они не хотят обрабатывать сетевые сбои, которые могут привести к невозможности кэшированного канала. Но это можно было бы легко устранить, поймав CommunicationException на методе, воссоздав канал и воспроизведя метод с помощью Reflection.
Тогда есть люди, которые считают, что это плохо для кэширования каналов, потому что все коммуникации будут проходить через один канал. См. Следующую статью.
http://social.msdn.microsoft.com/Forums/is/wcf/thread/9cbdf92a-a749-40ce-9ebe-3f2622cd78ee
Неужели это плохо? Вы не можете делиться каналами через потоки? Будет ли производительность страдать, потому что вызовы нескольких методов, сделанные на этот единственный канал, будут обрабатываться последовательно?
Я не нашел доказательств того, что обмен каналами ухудшит производительность. Я обнаружил, что использование кэшированного канала примерно в 5 раз быстрее, чем использование не кэшированного канала, даже если это означает необходимость использования Reflection для вызова методов кэшированными каналами.
Другим преимуществом является отсутствие необходимости окружать все ваши вызовы WCF операторами try/catch/finally для вызова Close(), Abort() или Dispose() на канале, когда вы закончите с ним. Мне кажется, что WCF сделал шаг в неправильном направлении, заставив разработчиков работать с ресурсами канала WCF. В .NET Remoting вы создали прокси-сервер, используя класс Activator, и вам не нужно было ничего делать, чтобы очистить его..NET Framework обработала все это для вас.
