Uso de contenedores IoC; específicamente Windsor

Question

Creo que la respuesta a esta pregunta es tan obvia que nadie se ha molestado en escribir sobre esto, pero es tarde y realmente no puedo entender esto.

He estado leyendo en contenedores IoC (Windsor en este caso) y me falta cómo hablas con el contenedor desde varias partes de tu código.

Obtuve DI, he estado haciendo ma's pobres DI (constructores vacíos llamando a constructores de inyección sobrecargados con implementaciones de parámetros predeterminadas) durante algún tiempo y puedo ver completamente el beneficio del contenedor. Sin embargo, me falta una pieza vital de información; ¿cómo se supone que debes hacer referencia al contenedor cada vez que necesites un servicio de él?

¿Creo un ataque global único que paso por alto? ¡Seguramente no!

Sé que debería llamar a esto:

WindsorContainer container = new WindsorContainer(new XmlInterpreter()); 

(por ejemplo) cuando quiero cargar mi config XML, pero entonces, ¿qué hago con el contenedor? ¿La creación de un nuevo contenedor cada vez que persiste la configuración cargada a través de algunos majicks estáticos internos o de lo contrario, o tengo que volver a cargar la configuración cada vez (supongo que no, o lifecycles couldnt).

No comprender esto me impide trabajar en cómo funcionan los ciclos de vida, y seguir adelante con el uso de algunos COI awsomeness

Gracias,

Andrew

Answer 1

El 99% de los casos es una instancia de contenedor por aplicación. Normalmente lo inicializa en Application_Start (para una aplicación web), like this.

Después de eso, depende realmente del consumidor del contenedor. Por ejemplo, algunos frameworks, como Monorail y ASP.NET MVC le permiten interceptar la creación de instancias (los controladores en este caso), por lo que solo registra los controladores y sus dependencias en el contenedor y eso es todo, cada vez que recibe una solicitud el contenedor se encarga de inyectar a cada controlador sus dependencias. Ver por ejemplo this ASP.NET MVC controller. En estos marcos, casi nunca necesita llamar o incluso hacer referencia al contenedor en sus clases, que es el uso recomendado.

Otros marcos no dejar que se obtiene en el proceso de creación fácilmente (como formularios web) por lo que tiene que recurrir a trucos como this one, o tirón las dependencias necesarias (es decir, una llamada explícita del contenedor). Para extraer dependencias, use una puerta de enlace estática al contenedor como this one o la descrita por maxnk. Tenga en cuenta que al hacer esto, en realidad está usando el contenedor como un Localizador de servicios, que no desacopla tanto como la inversión del control.(vea la diferencia here y here)

Espero que esto despeje sus dudas.

Answer 2

estoy usando una implementación de este interfaz:

public interface IResolver 
{ 
    object Resolve(Type type); 
    object Resolve(string name); 

    T Resolve<T>() where T : class; 
    T Resolve<T>(string name) where T : class; 
} 

que en realidad está envuelto en clase estática global, por ejemplo:

public static class Resolver // : IResolver 
{ 
    private static IResolver _current; 

    public static object Resolve(Type type) 
    { 
     return Current.Resolve(type); 
    } 

    public static object Resolve(string name) 
    { 
     return Current.Resolve(name); 
    } 

    public static T Resolve<T>() where T : class 
    { 
     return Current.Resolve<T>(); 
    } 

    public static T Resolve<T>(string name) where T : class 
    { 
     return Current.Resolve<T>(name); 
    } 

    private static IResolver Current 
    { 
     get 
     { 
      if (_current == null) 
      { 
       _current = new SpringResolver(); 
      } 

      return _current; 
     } 
    } 
} 

También trato de seguir la regla simple: use la clase Resolver como menos posible, en su lugar, inyecte servicios en los objetos que necesitan esos servicios.

Answer 3

Utilizo este ejemplo del blog de Michael Puleio sobre el uso de un HttpModule para manejar la acumulación de mis dependencias usando Unity. http://blogs.msdn.com/mpuleio/archive/2008/07/17/proof-of-concept-a-simple-di-solution-for-asp-net-webforms.aspx

Answer 4

En general, desea mantener solo una instancia durante toda la vida de la aplicación. Lo que hago la mayoría del tiempo es inicializar el contenedor cuando se inicia la aplicación, y luego uso las fábricas tipeadas para extraer objetos sin conocimiento del contenedor.

Otro enfoque popular es envolver la instancia del contenedor con la clase estática y usar esa clase estática para acceder a su contenedor (singleton). Puede encontrar un ejemplo de eso en la biblioteca Rhino.Commons de Ayende here. Sin embargo, este enfoque tiene graves inconvenientes y debe evitarse.

Answer 5

Como las otras respuestas aquí indican que hay muchas opciones, y de nuevo nos queda a nosotros mismos para descubrir qué es lo mejor en nuestro caso.

Dicho esto, la IMO que tiene un contenedor global al que se accede a través de su aplicación de alguna manera rompe el aislamiento ya que una gran cantidad de código ahora depende de la clase global. Además, para las aplicaciones que se dividen en varios ensamblados, el contenedor global debe estar disponible para todos estos ensamblajes.

Con Unity puede tener realmente un parámetro IUnityContainer en su constructor y el contenedor se inyectará automáticamente en la instancia cuando resuelva la clase. De esta forma, para los servicios que necesitan resolver otros servicios, los transfiere en el contenedor en lugar de forzar a la clase a hacer referencia a la clase externa.

No estoy seguro de cómo otros marcos admiten este escenario (Windsor inyectará IKernel).