Marcos de inyección de dependencia: ¿Por qué me importa?

Question

Estaba leyendo más de Injection by Hand y Ninjection (así como Why use Ninject). Me encontré con dos piezas de confusión:

1. La inyección por técnica de mano que ya estoy familiarizado con, pero no estoy familiarizado con Ninjection, y por lo tanto no estoy seguro de cómo el programa completo funcionaría. Tal vez sería útil proporcionar un programa completo en lugar de, como se hace en esa página, mostrar un programa dividido en piezas

2. Todavía no entiendo cómo esto facilita las cosas. Creo que me estoy perdiendo algo importante. Puedo ver cómo un marco de inyección sería útil si estuvieras creando un grupo de inyecciones y luego cambiaras de un grupo grande a la vez (esto es útil para burlarse, entre otras cosas), pero creo que hay más en ello. que eso. Pero no estoy seguro de qué. O tal vez solo necesito más ejemplos de por qué esto es emocionante para llevar a casa el punto.

Answer 1

Al inyectar sus dependencias sin un marco DI, usted termina con un código de flecha en toda su aplicación que le dice a las clases cómo construir sus dependencias.

public Contact() 
     : this(new DataGateWay()) 
    { 
    } 

Pero si se utiliza algo así como Ninject, todo el código de la flecha está en un solo lugar por lo que es más fácil cambiar una dependencia para todas las clases que lo usan.

internal class ProductionModule : StandardModule 
{ 
    public override void Load() 
    { 
     Bind<IDataGateway>().To<DataGateWay>(); 
    } 
} 

Answer 2

La inyección de dependencias que utiliza la mayoría de los marcos se puede configurar en tiempo de ejecución, sin necesidad de volver a compilar.

Answer 3

Me gusta mucho el aspecto de autovinculación de algunos frameworks ... cuando no tiene que preocuparse acerca de qué tipo de sus tipos necesitan ser instanciados.

EDIT: leí this article by Ayende @ Rahien. Y realmente apoyo su punto.

Answer 4

La inyección de dependencias puede ser realmente interesante si obtiene su código hasta el punto en que hay muy pocas dependencias en el código. Algunos marcos de inyección de dependencia le permitirán definir sus dependencias en un archivo de configuración. Esto puede ser muy útil si necesita una pieza de software realmente flexible que necesite cambiarse sin modificar el código. Por ejemplo, el software de flujo de trabajo es un candidato principal para este tipo de solución.

Answer 5

Le permite probar fácilmente su código burlándose de las interfaces que necesita para un bloque de código en particular. También le permite intercambiar fácilmente la funcionalidad sin romper otras partes del código.

Se trata de la cohesión y el acoplamiento.

Probablemente no veas el beneficio en proyectos pequeños, pero una vez que pasas de pequeño se hace realmente evidente cuando tienes que hacer cambios en el sistema. Es muy fácil cuando has usado DI.

Answer 6

Dependency Injection es esencial para el Component Driven Development. Este último permite construir realmente complejas aplicaciones de una manera mucho más eficiente y confiable.

Además, permite separar las preocupaciones comunes de corte transversal del otro código (esto da como resultado una base de código más reutilizable y flexible).

Enlaces relacionados:

• Inversion of Control and Dependency Injection - Wiki
• Component-Driven Development - Wiki
• Cross-cutting concerns - Wiki

Answer 7

Todavía no entiendo realmente cómo esto facilita las cosas. Creo que me estoy perdiendo algo importante.

No sería sería grande si sólo tuvimos que desarrollar componentes discretos, donde cada uno proporcionan funcionalidad distinta podríamos entender fácilmente, volver a usar y mantener. Donde solo trabajamos en componentes.

Lo que nos impide hacerlo, es que necesitamos alguna infraestructura que de alguna manera pueda combinar y administrar estos componentes en una aplicación en funcionamiento automáticamente. La infraestructura que hace esto está disponible para nosotros, un marco del COI.

Así que un marco IOC no es aproximadamente administrando dependencias o pruebas o configuración. En cambio, es aproximadamente que gestiona la complejidad, al permitirle trabajar y pensar solo en los componentes.