Почему кеширование каналов WCF - это плохо?

Я читал много статей о 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 сделала все это за вас.