¿Debería el servicio WCF ser típicamente singleton o no?

Question

Creo que Jimmy Nillson dijo que generalmente creaba sus servicios web singletons. ¿Es este el método preferido, y con WCF? Además de hacer que los métodos de servicio sean estáticos, ¿hay algo más que hacer?

Answer 1

buenas respuestas, pero creo que hay un problema en la pregunta original. El "uso típico" de una tecnología es una pregunta mal formada. Nadie tiene un escenario "típico", y debe revisar los requisitos de su problema particular antes de decidir una implementación o enfoque. Sus requisitos deben informar su solución.

Por ejemplo, Singletons [es decir, el patrón Singleton] es simplemente otra herramienta más en nuestra caja, y como cualquier herramienta, hay casos en los que funciona, y otros no. Específicamente, si necesita centralizar la lógica de negocios [más aplicable en una aplicación independiente que un servicio WCF remoto], o compartir memoria o un recurso, un Singleton funciona bien. Por supuesto, si está compartiendo la lógica de negocios, el estado se mantiene en la pila de llamadas, y el multithreading es irrelevante. Si comparte la memoria entre las llamadas de los consumidores, entonces el multi-threading es un problema. En cuanto a WCF, hay dos modos [en realidad tres, pero el tercero es un caso especial de la primera] del comportamiento multi-threading puede especificar,

// we are specifying that this service implementation is single-threaded 
// and WCF should permit *at most* one call at a time. Any requests made 
// simultaneously/concurrently are queued. 
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)] 
public class SingleThreadedNonThreadSafeService : IService { ... } 

y

// we are specifying that this service implementation is multi-threaded 
// and [hopefully!] thread-safe. WCF should permit any number of threads, 
// or any number of simultaneous concurrent calls. 
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)] 
public class MultiThreadedThreadSafeService : IService { ... } 

Los comentarios XML para ConcurrencyMode básicamente dicen lo mismo que arriba.

Si NO necesita compartir la lógica de negocio o de la memoria entre los consumidores, a continuación, NO utilizar un Singleton, el "modelo" no encajan el problema. ¡Es como forzar una zapatilla de cristal en el pie de una madrastra! Y nadie debería tener que ver eso.

---

Por el contrario, si no se comparte un estado entre llamadas, aloje una instancia por llamada \ sesión.

Answer 2

Normalmente NO. Los singletons son un desastre, ya que para que funcionen bien, tendrás que hacerlos de múltiples subprocesos, y eso es solo pedir problemas a menos que realmente realmente sepas lo que estás haciendo.

La mejor práctica para WCF es usar instanciación por llamada: cada solicitud obtiene su propia copia de la clase de servicio, sin problemas de subprocesamiento múltiple, buen rendimiento, almacena todo lo que necesita persistir en una base de datos, funciona como un encanto.

El único escenario real donde singleton podría tener sentido es si tiene que hacer que todas las solicitudes de servicio sean manejadas por un recurso físico que esté disponible solo en una instancia individual; si su servicio singleton serializa y protege un único recurso, entonces tiene sentido usarlo.

De lo contrario, ¡ahórrese el problema! :-)

Answer 3

Los servicios WCF de Singleton casi nunca deberían usarse: ¡los Singleton son el enemigo de la escalabilidad! Solo tienen sentido en escenarios extraños: iniciar sesión en un único archivo, un solo puerto de comunicaciones o dispositivo de hardware.

Como Marc dice que la mejor opción para la escalabilidad con WCF es por servicios de llamada (ofrecen la mejor compensación entre rendimiento y escalabilidad). Los servicios por llamada también funcionan muy bien con el equilibrio de carga.