comportamiento Singleton-como con la inyección de dependencias

Después de hacer algunas investigaciones sobre MEF me encontré con el CreationPolicy.Shared propiedad que de acuerdo con MSDN:comportamiento Singleton-como con la inyección de dependencias

Especifica que una sola instancia compartida de los asociados ComposablePart habrá creado por CompositionContainer y compartido por todos los solicitantes.

Suena bien siempre y cuando siempre me asegure de que uno y solo un contenedor tenga acceso a la clase que exporto con esta política. Entonces, ¿cómo puedo garantizar que solo un contenedor tenga acceso a mi tipo exportado? Aquí está mi situación:

Tengo un servicio de Windows que necesita acceder a una clase de tipo singleton para algunos datos en memoria. Los datos no son persistentes, por lo que quiero que se creen de nuevo cada vez que se inicie el servicio, pero no sirven para nada una vez que se detiene el servicio. Múltiples hilos en mi servicio necesitarán leer y escribir en este objeto de una manera segura para hilos, por lo que mi plan inicial era heredar de ConcurrentDictionary para asegurar las operaciones de seguridad de subprocesos.

Los hilos que entrarán en esta clase todos heredan de una única clase base abstracta, así que ¿hay alguna manera de que esta clase (y solo esta clase) la importe de MEF y haga que funcione como yo quiero?

gracias por cualquier consejo que pueda tener, soy bastante nuevo al MEF, así que todavía estoy aprendiendo los entresijos

Fuente

2012-06-15 snappymcsnap

He usado ninject con su modo "como singleton" para un enlace de gran efecto. Solo tenga cuidado de mantener lo que MEF proporciona de esa manera seguro para hilos (sin efectos secundarios ni graciosos). – bluevector

@jonnyGold Gracias, no he usado Ninject antes ... ¿se puede utilizar de alguna manera en MEF o es su propio framework DI? – snappymcsnap

Es su propio marco. Puedes agarrarlo a través de Nuget y hay especializaciones para MVC y WCF. Lo que más me gusta de él es que los enlaces están declarados en código, por lo que no puedes cometer un error de coincidencia de tipos. O un error tipográfico, para el caso. Además, los enlaces contextuales son realmente poderosos. – bluevector

Si es absolutamente necesario ser un producto único entre los diferentes contenedores, se puede utilizar un constructor privado y exponer una propiedad estática Instance, como si se tratara de un singleton "clásico" no administrado por contenedor. Luego, en la raíz composición, utilice ComposeExportedValue para registrarlo en el contenedor:

container.ComposeExportedValue(MySingleton.Instance);

Fuente

2012-06-15 19:30:52

no del todo, si es posible me gustaría exponerlo solo a un contenedor y el marco de MEF se asegurará de que sea un singleton por defecto. Sin embargo, si esto no es posible, no veo ninguna ventaja de usar MEF para esto en primer lugar. – snappymcsnap

No estoy seguro de entender exactamente lo que estás preguntando. Debe asegurarse de que solo exista un contenedor. Luego 'CreationPolicy.Shared' dará como resultado un singleton. ¿Estás pensando en crear varios contenedores? Porque eso sería atípico. –

Siempre se puede utilizar el tipo de Lazy ya que bloquea otros hilos como se describe en esta entrada del blog: http://geekswithblogs.net/BlackRabbitCoder/archive/2010/05/19/c-system.lazylttgt-and-the-singleton-design-pattern.aspx

Fuente

2012-06-15 19:47:46 kappasims

comportamiento Singleton-como con la inyección de dependencias

Respuesta

Cuestiones relacionadas