8

tengo 4 proyectos:inyección y el proyecto de la estructura de dependencias para aplicaciones de consola

Core (IServer):

  • sistema
  • System.Core

DependencyResolver:

  • Core
  • StructureMap

Infraestructura (Servicio):

  • Core
  • dependencia externa

Consola:

  • Core
  • DependencyResolver

REQUERIMIENTOS:

Estoy tratando de utilizar StructureMap sólo en el DependencyResolver. Además, la aplicación de la Consola no debe saber nada sobre Infrastucture.

Cuando no quiero hacer referencia a StructureMap en mi aplicación de consola, tengo que construir un ServiceLocator.

En el DependencyResolver Tengo un programa previo que es responsable de llamar a las cosas StructureMap registro (Registro)

En mi aplicación de consola Quiero obtener una instancia. Para esto necesito hacer referencia a StructureMap. Otra forma sería escribir una pequeña envoltura alrededor de los métodos de resolución de StructureMaps.

¿Hay alguna otra forma mejor de desacoplar la consola de StructureMap?

+0

Suena un poco sobre ingeniería. ¿Cómo se ve tu código? ¿Por qué necesita un localizador de servicios si su resolución de dependencias ya encapsula el mapa de la estructura? – SimonC

+0

¿Has visto http://bootstrapper.codeplex.com/ –

+0

El nombre de la resolución de la dependencia no es la mejor opción con respecto a lo que el componente es responsable. Por el momento, su única responsabilidad es registrar dependencias. Entonces mi pregunta es más acerca de la parte de resolución de Dependency Injection. – Rookian

Respuesta

17

Mientras veo un motivo para separar el registro de IoC, resolver, liberar de la implementación de la aplicación, no veo ningún motivo por el que el contenedor IoC no deba estar en la aplicación de consola (la raíz de composición) y Implementación de aplicaciones en otro ensamblado en su lugar.

De esta manera la aplicación de consola es muy fácil:

  1. crear el contenedor
  2. Cargar la configuración del contenedor
  3. resolver sobre la solicitud
  4. llamada de ejecución de la aplicación y pasar los argumentos de la consola junto
  5. deseche el contenedor cuando la aplicación salga del método de ejecución

Con SM que se vea más o menos así:

public void Main(params string[] args) 
{ 
    using (var container = new Container()) 
    { 
     container.LoadAllConfigurationModules(); 
     container.AddRegistry<SomeRegistry>(); 
     container.GetInstance<Application>().Run(args); 
    } 
} 

Para que las cosas no se puede crear en el arranque se crea una interfaz de fábrica en su conjunto de aplicación:

interface ISomeFactory { ISomeDependency CreateSomeDependency() } 

e implementar esta interfaz en el aplicación de consola al inyectar el contenedor y usarlo para resolver la instancia. Supongo que la implementación SM se ve así:

public class SomeFactory : ISomeFactory 
{ 
    public SomeFactory(IContainer sontainer) { this.container = container; } 
    ISomeDependency CreateSomeDependency() { this.container.GetInstance<ISomeDependency>(); } 
} 

otro contenedor IoC siquiera tiene la funcionabilidad para implementar estas fábricas interfaz automáticamente.

+0

Con su solución, debe hacer referencia a todas las bibliotecas en la aplicación de la consola. Porque la raíz de la composición se encuentra directamente en la clase principal. – Rookian

+6

Sí, eso es correcto. Pero, ¿dónde está el problema? Este ensamblaje tiene exactamente un propósito: ¡arranque! –

+0

ah ok. Tu segunda declaración es importante. Eso tiene sentido. – Rookian

Cuestiones relacionadas