He estado leyendo muchos artículos de WCF en línea y parece que la mayoría de las personas almacenan en caché los objetos de ChannelFactory pero no los canales en sí. Parece que la mayoría de las personas teme usar el caché de canales porque no quieren manejar las fallas de red que podrían inutilizar el canal en caché. Pero eso podría solucionarse fácilmente atrapando la CommunicationException en el método, recrear el canal y reproducir el método usando Reflection.¿Por qué el almacenamiento en caché de canales WCF es malo?
Luego hay personas que piensan que es malo hacer caché de canales porque todas las comunicaciones pasarán por un solo canal. Ver el siguiente artículo.
http://social.msdn.microsoft.com/Forums/is/wcf/thread/9cbdf92a-a749-40ce-9ebe-3f2622cd78ee
¿Este es necesariamente algo malo? ¿No puedes compartir canales entre hilos? ¿Sufrirá un rendimiento debido a que las llamadas a múltiples métodos realizadas en este canal único serán procesadas en serie?
No he encontrado evidencia de que compartir canales disminuya el rendimiento. Lo que encontré es que usar un canal en caché es aproximadamente 5 veces más rápido que usar un canal no almacenado en caché, incluso si eso significa tener que usar Reflection para hacer las llamadas a métodos en los canales en caché.
La otra ventaja es no tener que rodear todas sus llamadas WCF con declaraciones try/catch/finally para llamar a Close(), Abort(), o Dispose() en el canal cuando haya terminado con ellas. Para mí, parece que WCF dio un paso en la dirección equivocada forzando a los desarrolladores a tener que administrar los recursos del canal WCF. En .NET Remoting, creó el proxy utilizando la clase Activator y no tuvo que hacer nada para limpiarlo. .NET Framework manejó todo eso por ti.
Esta es una buena pregunta. –