error - ¿El servicio WCF debería ser singleton o no?
metadata publishing for this service is currently disabled (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 dice Marc, la mejor opción para la escalabilidad con WCF son los servicios por llamada (ofrecen la mejor compensación entre rendimiento y escalabilidad). Los servicios por llamada también funcionan muy bien con el equilibrio de carga.
Creo que Jimmy Nillson dijo que, en general, hizo 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?
Típicamente 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 utilizadas / manejadas por un recurso físico que esté disponible solo en una sola instancia; si su servicio singleton serializa y protege un único recurso, entonces tiene sentido para usarlo
De lo contrario, ¡ahórrese el problema! :-)
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 solo otra herramienta en nuestro recuadro, y como cualquier herramienta, hay casos en 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 del primero] de comportamiento de subprocesamiento múltiple que 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 es necesario que comparta la lógica de negocios o la memoria entre los consumidores, NO utilice un Singleton, el "modelo" NO se ajusta al 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 ningún estado entre llamadas, aloje una instancia por llamada / sesión.