2009-11-19 6 views
7

Soy nuevo en el mundo de IoC y tengo un problema al implementarlo en una aplicación Winforms. Tengo una aplicación Winform de aplicación extremadamente básica que usa MVC, es un controlador que hace todo el trabajo y un diálogo de trabajo (obviamente con un controlador). Así que cargo todas mis clases en mi contenedor IoC en program.cs y creo el controlador principal de formulario usando el contenedor. Pero aquí es donde tengo problemas, solo quiero crear el controlador de diálogo de trabajo cuando se usa y dentro de una declaración de uso.Cómo no pasar el contenedor cuando se usa IoC en Winforms

Al principio pasé en el contenedor, pero he leído que esto es una mala práctica y que más del contenedor es estático y quiero probar esta clase en una unidad.

Entonces, ¿cómo se crean las clases en una prueba de unidad de manera amigable sin pasar en el contenedor, yo estaba considerando el patrón abstracto de fábrica, pero eso solo resolvería mi problema sin usar el IoC.

no estoy usando ningún marco famosa, pedí prestado uno básico de esta entrada del blog http://www.kenegozi.com/Blog/2008/01/17/its-my-turn-to-build-an-ioc-container-in-15-minutes-and-33-lines.aspx

¿Cómo puedo hacer esto con la COI? ¿Es este el uso incorrecto para IoC?

Respuesta

7

La publicación de Ken es muy interesante, pero está en el punto en el que vale la pena aprender más sobre los contenedores de IoC de "producción", ya que algunos admiten este escenario.

En Autofac por ejemplo, se puede 'generar' una fábrica como delegado:

builder.RegisterGeneratedFactory<Func<IDialogController>>(); 

Luego, en su forma principal:

class MainForm ... { 

    Func<IDialogController> _controllerFactory; 

    public MainForm(Func<IDialogController> controllerFactory) { ... } 

    void ShowDialog() { 
    using (var controller = _controllerFactory()) 
    { 
    } 
    } 

Autofac rellenará el parámetro constructor controllerFactory en tiempo de ejecución . En las pruebas de su unidad, puede proporcionar fácilmente una lambda al constructor.

1

En general, solo paso en una interfaz a una clase de fábrica.

+0

Pensé en eso, pero no elimina la necesidad de IoC en conjunto –

+0

@ L2Type: IoC/DI no requiere una biblioteca de contenedores, esto es IoC. Sin embargo, cuando tiene clases con varias dependencias que tienen dependencias, apreciará el cableado que la biblioteca de contenedores le compra. – TrueWill

1

La única solución razonable que encontré es hacer su contenedor Singleton. Algunos de los marcos de IoC hacen eso por usted, pero es posible que deba implementar su propia implementación de Singleton. Eche un vistazo a Jon Skeet's ideas.

Buena suerte con MVC en Winforms. Es una curva de aprendizaje empinada, que solo estoy empezando a ascender.

+0

Intenté implementar MVC en WinForms antes de trabajar, pero terminamos con una solución híbrida que no es exactamente MVC y realmente lo es. Es una lucha cuesta arriba. –

+0

Uno de los beneficios de un contenedor IoC es deshacerse de Singletons. La administración de por vida es manejada por el contenedor. Si convierte el contenedor en Singleton, acoplará todas sus clases al contenedor y ya no podrá ver las dependencias de una clase de un vistazo. – TrueWill

+0

¿No estoy seguro de cómo no puedo ver mis dependencias de clase? Me resulta extremadamente difícil no tener un solo singleton en la aplicación :) Sé que uno debe usar sabiamente el singleton, pero creo que es justificable en algunos casos, como la aplicación winforms (e incluso los de complejidad moderada). ¿Creen? hay otras opciones aparte de la pasión del contenedor en todas partes y contaminando su código y teniendo un contenedor singleton? –

Cuestiones relacionadas