.NET FrameworkInyección de dependencia


Observaciones

Problemas resueltos por inyección de dependencia

Si no utilizáramos la inyección de dependencia, la clase Greeter podría verse más como esto:

public class ControlFreakGreeter
{
    public void Greet()
    {
        var greetingProvider = new SqlGreetingProvider(
            ConfigurationManager.ConnectionStrings["myConnectionString"].ConnectionString);
        var greeting = greetingProvider.GetGreeting();
        Console.WriteLine(greeting);
    }
}

Es un "control freak" porque controla la creación de la clase que proporciona el saludo, controla de dónde proviene la cadena de conexión SQL y controla la salida.

Al usar la inyección de dependencia, la clase Greeter renuncia a esas responsabilidades en favor de una sola responsabilidad, escribiendo un saludo que se le proporciona.

El principio de inversión de dependencia sugiere que las clases deberían depender de abstracciones (como interfaces) en lugar de otras clases concretas. Las dependencias directas (acoplamiento) entre clases pueden dificultar progresivamente el mantenimiento. Dependiendo de las abstracciones se puede reducir ese acoplamiento.

La inyección de dependencia nos ayuda a lograr esa inversión de dependencia porque lleva a escribir clases que dependen de abstracciones. La clase Greeter "no sabe" nada en absoluto sobre los detalles de implementación de IGreetingProvider e IGreetingWriter . Solo se sabe que las dependencias inyectadas implementan esas interfaces. Eso significa que los cambios en las clases concretas que implementan IGreetingProvider e IGreetingWriter no afectarán a Greeter . Tampoco los reemplazará con implementaciones completamente diferentes. Solo los cambios en las interfaces lo harán. Greeter está desacoplado.

ControlFreakGreeter es imposible realizar una prueba de unidad correctamente. Queremos probar una pequeña unidad de código, pero en lugar de eso, nuestra prueba incluiría conectarse a SQL y ejecutar un procedimiento almacenado. También incluiría probar la salida de la consola. Debido a que ControlFreakGreeter hace tanto, es imposible realizar pruebas aisladas de otras clases.

Greeter es fácil de realizar una prueba unitaria porque podemos inyectar implementaciones simuladas de sus dependencias que son más fáciles de ejecutar y verificar que llamar a un procedimiento almacenado o leer la salida de la consola. No requiere una cadena de conexión en app.config.

Las implementaciones concretas de IGreetingProvider y IGreetingWriter pueden ser más complejas. Ellos, a su vez, pueden tener sus propias dependencias que se inyectan en ellos. (Por ejemplo, inyectaríamos la cadena de conexión SQL en SqlGreetingProvider ). Pero esa complejidad está "oculta" de otras clases que solo dependen de las interfaces. Eso hace que sea más fácil modificar una clase sin un "efecto dominó" que requiere que realicemos los cambios correspondientes a otras clases.

Inyección de dependencia Ejemplos relacionados