Singleton o no

Question

Tengo un servicio de Windows en ejecución. Dentro de este servicio he alojado algunos servicios (WCF). Necesito tener algún tipo de clase de "titular de datos de memoria". El objetivo de esta clase es mantener datos no persistentes siempre que se esté ejecutando el servicio de Windows. Esta clase debe ser accesible a través de los servicios de WCF. Ponen algunos valores en esta clase o recuperan algunos valores de esta clase.

Lo primero que me vino a la mente fue una clase singleton. Creo que este patrón es perfecto para esta situación. Pero luego leí una publicación que dice que la clase singleton no es realmente tan buena.

Entonces, ¿hay alguna alternativa para este tipo de situación? ¿O está bien el singleton para esto? ¿Qué tal un método de fábrica? Pero entonces, ¿dónde encontraría las referencias para los objcects?

Answer 1

El patrón de diseño Singleton realmente se debe volver a etiquetar como antipatrón. Es malvado. No lo uses

Una mejor alternativa es usar Dependency Injection (DI) e inyectar una clase que puede usar para contener los datos no persistentes que necesita.

Mucha gente no se da cuenta de que WCF admite patrones de Inyección de Dependencia (DI) como Constructor Injection sin demasiada molestia.

Si usted alcance la clase inyectada como un objeto de larga duración (normalmente conocida como Singleton estilo de vida, pero no debe ser confundido con el patrón de diseño Singleton) se puede mantener el acceso a la misma instancia de una llamada.

Sin embargo, siempre que use objetos compartidos (ya sea que use Singleton como patrón de diseño o estilo de por vida) debe estar preparado para manejar problemas de multihilo.

Entre otras muchas cosas, this post describe cómo inyectar dependencias en una implementación de servicio WCF cuando no tiene un constructor predeterminado.

Answer 2

¿Por qué necesitaría un singleton para esto?

¿Realmente necesita limitar las instancias de esta clase a una sola instancia? De lo contrario, no use un singleton, no lo necesita y solo agregará complejidad a su clase.

Answer 3

Me interesa saber por qué a la gente no le gusta el singleton, con gusto lo usaría para el escenario anterior a menos que alguien me diga algunas buenas razones por las que no.

Es un patrón sencillo de entender y aplicar y estoy pensando hacer que sea sencillo es una buena cosa en tiempo de 6 meses o cuando soemone más tiene que mantener su código

EDITAR Después de haber hecho un poco más Investigando por qué a algunas personas no les gusta el patrón único, se abordan un conjunto útil de alternativas en la pregunta: What's Alternative to Singleton Esto trata con los inconvenientes de la prueba unitaria del patrón.

EDIT 2 Finalmente estoy convencido de que el singelton puede ser malo.http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html aclara que, en términos de mantenimiento, declarar una dependencia a nivel de API hace que sea más fácil para los programadores controlar las dependencias.