¿Explicación más simple de cómo funciona un contenedor DI?

Question

En términos simples y/o en pseudocódigo de alto nivel, ¿cómo funciona un contenedor DI y cómo se usa?

Answer 1

En su núcleo, un contenedor DI crea objetos basados ​​en mappings entre interfaces y tipos concretos.

Esto le permitirá solicitar un tipo abstracto del contenedor:

IFoo f = container.Resolve<IFoo>(); 

Esto requiere que haya previamente configurado el contenedor al mapa de IFoo a una clase concreta que implemente IFoo (por ejemplo Foo)

Esto en sí mismo no sería particularmente impresionante, pero DI Contenedores hacer más:

• Ellos usan Auto-cableado que significa que se pueden calcular automáticamente que si IFoo asigna a Foo y mapas Ibar Bar, pero Foo tiene una dependencia en IBar, creará una instancia de Foo con una barra cuando solicite IFoo.
• Gestionan el de por vida de componentes. Muchos quieren una nueva instancia de Foo todo el tiempo, pero en otros casos es posible que desee la misma instancia. Incluso puede desear nuevas instancias de Foo cada vez, pero la Barra inyectada debería seguir siendo la misma instancia.

Una vez que comience a tratar de administrar manualmente composición y vidas usted debe comenzar a apreciar los servicios prestados por un DI de contenedores :)

Muchos DI contenedores pueden hacer mucho más que el anterior, pero aquellos son los servicios centrales. La mayoría de los contenedores ofrecen opciones para configuring via either code or XML.

Cuando se trata de uso correcto de contenedores, Krzysztof Kozmic acaba de publicar a good overview.

Answer 2

Configura un contenedor DI para que conozca sus interfaces y tipos: cómo cada interfaz se correlaciona con un tipo.

Cuando llama al Resolve en él, mira la asignación y devuelve el objeto mapeado que ha solicitado.

Algunos contenedores DI usan convenciones sobre la configuración, donde, por ejemplo, si define una interfaz ISomething, buscará un tipo concreto Something para instanciar y devolver.

Answer 3

"no es nada más que una suposición tabla hash de objetos."

Aunque lo anterior es una subestimación masiva que es la manera más fácil de pensar en ellos. Dada la recopilación, si solicita la misma instancia de una clase, el contenedor DI decidirá entre darle una versión almacenada en caché o una nueva, y así sucesivamente.

Su uso lo hace más fácil y más limpio cuando se trata de cablear dependencias. Imagina que tienes las siguientes pseudo clases.

class House(Kitchen, Bedroom) 
    // Use kitchen and bedroom. 
end 

class Kitchen() 
    // Code... 
end 

class Bedroom() 
    // Code... 
end 

La construcción de una casa es un dolor sin un contenedor de DI, se tendría que crear una instancia de un dormitorio, seguido por una instancia de una cocina. Si esos objetos también tuvieran dependencias, necesitarías cablearlos. A su vez, puede gastar muchas líneas de código solo conectando objetos. Solo entonces podrías crear una casa válida. Usando un contenedor DI/IOC (Inversión de control) dices que quieres un objeto doméstico, el contenedor DI creará recursivamente cada una de sus dependencias y te devolverá una casa.

Sin DI/COI envase:

house = new House(new Kitchen(), new Bedroom()); 

Con DI/COI envase:

house = // some method of getting the house 

Al final del día que hacer el código fácil de seguir, fácil de escribir y cambiar la responsabilidad de cablear objetos juntos lejos del problema en cuestión.