Inyección de dependencia para principiantes

¡Hola, Habr!



Nos estamos preparando para lanzar la segunda edición del legendario libro de Mark Siman " Dependency Injection on the .NET Platform ".







Incluso en un libro tan voluminoso, difícilmente es posible cubrir completamente un tema de este tipo. Pero le ofrecemos una traducción abreviada de un artículo muy accesible que describe la esencia de la inyección de dependencia en un lenguaje simple, con ejemplos en C #.



El propósito de este artículo es explicar el concepto de inyección de dependencia y mostrar cómo se programa en un proyecto determinado. De Wikipedia:

La inyección de dependencias es un patrón de diseño que separa el comportamiento de la resolución de dependencias. Por tanto, es posible separar componentes que dependen en gran medida unos de otros.

La inyección de dependencia (o DI) le permite proporcionar implementaciones y servicios a otras clases para su consumo; el código permanece muy débilmente acoplado. El punto principal en este caso es este: en lugar de implementaciones, puede sustituir fácilmente otras implementaciones y, al mismo tiempo, debe cambiar un mínimo de código, ya que la implementación y el consumidor probablemente estén conectados solo por un contrato .



En C #, esto significa que sus implementaciones de servicios deben cumplir con los requisitos de la interfaz, y cuando la creación de los consumidores por sus servicios, debe dirigirse a la interfaz , no la implementación, y requieren la aplicación que debe facilitarse o implementado para usted.para que no tenga que crear las instancias usted mismo. Con este enfoque, no tiene que preocuparse a nivel de clase acerca de cómo se crean las dependencias y de dónde vienen; en este caso, solo el contrato es importante.

Inyección de dependencia por ejemplo

Veamos un ejemplo en el que DI puede resultar útil. Primero, creemos una interfaz (contrato) que nos permitirá realizar alguna tarea, por ejemplo, registrar un mensaje:

public interface ILogger {  
  void LogMessage(string message); 
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Tenga en cuenta: esta interfaz no describe en ninguna parte cómo se registra un mensaje y dónde se registra; aquí simplemente se pasa la intención de escribir la cadena en algún repositorio. A continuación, creemos una entidad que utilice esta interfaz. Digamos que creamos una clase que realiza un seguimiento de un directorio específico en el disco y, tan pronto como se realiza un cambio en el directorio, registra el mensaje correspondiente:

public class DirectoryWatcher {  
 private ILogger _logger;
 private FileSystemWatcher _watcher;

 public DirectoryWatcher(ILogger logger) {
  _logger = logger;
  _watcher = new FileSystemWatcher(@ "C:Temp");
  _watcher.Changed += new FileSystemEventHandler(Directory_Changed);
 }

 void Directory_Changed(object sender, FileSystemEventArgs e) {
  _logger.LogMessage(e.FullPath + " was changed");
 }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

En este caso, lo más importante a tener en cuenta es que se nos proporciona el constructor que necesitamos, que implementa ILogger



. Pero, nuevamente, tenga en cuenta: no nos importa dónde va el registro o cómo se crea. Podemos programar con la interfaz en mente y no pensar en nada más.



Por lo tanto, para crear una instancia nuestra DirectoryWatcher



, también necesitamos una implementación lista para usar ILogger



. Sigamos adelante y creemos una instancia que registre mensajes en un archivo de texto:

public class TextFileLogger: ILogger {  
 public void LogMessage(string message) {
  using(FileStream stream = new FileStream("log.txt", FileMode.Append)) {
   StreamWriter writer = new StreamWriter(stream);
   writer.WriteLine(message);
   writer.Flush();
  }
 }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Creemos otro que escriba mensajes en el registro de eventos de Windows:

public class EventFileLogger: ILogger {  
 private string _sourceName;

 public EventFileLogger(string sourceName) {
  _sourceName = sourceName;
 }

 public void LogMessage(string message) {
  if (!EventLog.SourceExists(_sourceName)) {
   EventLog.CreateEventSource(_sourceName, "Application");
  }
  EventLog.WriteEntry(_sourceName, message);
 }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Ahora tenemos dos implementaciones separadas que registran mensajes de formas muy diferentes, pero ambas lo hacen ILogger



, lo que significa que cualquiera de las dos se puede usar donde se necesite una instancia ILogger



. A continuación, puede crear una instancia DirectoryWatcher



y decirle que use uno de nuestros registradores:

ILogger logger = new TextFileLogger();  
DirectoryWatcher watcher = new DirectoryWatcher(logger);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

O, simplemente cambiando el lado derecho de la primera línea, podemos usar una implementación diferente:

ILogger logger = new EventFileLogger();  
DirectoryWatcher watcher = new DirectoryWatcher(logger);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Todo esto sucede sin ningún cambio en la implementación de DirectoryWatcher, y esto es lo más importante. Estamos inyectando nuestra implementación de registrador en el consumidor para que el consumidor no tenga que crear una instancia por su cuenta. El ejemplo que se muestra es trivial, pero imagine cómo sería usar estas técnicas en un proyecto a gran escala donde tiene múltiples dependencias y hay muchas veces más consumidores usándolas. Y luego, de repente, hay una solicitud para cambiar el método que registra los mensajes (digamos, ahora los mensajes deben registrarse en el servidor SQL para fines de auditoría). Si no usa la inyección de dependencia de una forma u otra, tendrá que revisar cuidadosamente el código y realizar cambios donde sea que se cree y luego se use el registrador. En un proyecto grande, dicho trabajo puede resultar engorroso y propenso a errores.Con DI, simplemente cambia la dependencia en un lugar, y el resto de la aplicación realmente absorberá los cambios y comenzará a usar inmediatamente el nuevo método de registro.



En esencia, resuelve el clásico problema de software de dependencia pesada, y DI le permite crear código poco acoplado que es extremadamente flexible y fácil de modificar.

Envases de inyección de dependencia

Muchos marcos de inyección de DI que puede descargar y usar simplemente van un paso más allá y usan un contenedor para la inyección de dependencia. En esencia, es una clase que almacena asignaciones de tipos y devuelve una implementación registrada para un tipo determinado. En nuestro ejemplo simple, podremos solicitar una instancia del contenedor ILogger



, y nos devolverá la instancia TextFileLogger



, o cualquier otra instancia con la que inicializamos el contenedor.



En este caso, tenemos la ventaja de que podemos registrar todo tipo de mapeos en un solo lugar, generalmente donde ocurre el evento de lanzamiento de la aplicación, y esto nos permitirá ver rápida y claramente qué dependencias tenemos en el sistema. Además, en muchos marcos profesionales, puede configurar la vida útil de dichos objetos, ya sea creando instancias nuevas con cada nueva solicitud o reutilizando una instancia en varias llamadas.



El contenedor generalmente se crea de tal manera que podemos acceder al 'resolutor' (el tipo de entidad que nos permite solicitar instancias) desde cualquier lugar del proyecto.

Finalmente, los marcos profesionales suelen apoyar el fenómeno de las subdependencias.- en este caso, la propia dependencia tiene una o más dependencias de otros tipos, también conocidos por el contenedor. En este caso, el solucionador también puede cumplir con esas dependencias, devolviéndole una cadena completa de dependencias creadas correctamente que corresponden a sus asignaciones de tipos.



Creemos nosotros mismos un contenedor DI muy simple para ver cómo funciona todo. Dicha implementación no admite dependencias anidadas, pero le permite asignar una interfaz a una implementación y luego solicitar la implementación en sí:

public class SimpleDIContainer {  
 Dictionary < Type, object > _map;
 public SimpleDIContainer() {
   _map = new Dictionary < Type, object > ();
  } 

/// <summary> 
///       ,    . 
/// </summary> 
/// <typeparam name="TIn">The interface type</typeparam> 
/// <typeparam name="TOut">The implementation type</typeparam> 
/// <param name="args">Optional arguments for the creation of the implementation type.</param> 
 public void Map <TIn, TOut> (params object[] args) {
   if (!_map.ContainsKey(typeof(TIn))) {
    object instance = Activator.CreateInstance(typeof(TOut), args);
    _map[typeof(TIn)] = instance;
   }
  } 

/// <summary> 
///  ,  T 
/// </summary> 
/// <typeparam name="T">The interface type</typeparam>
 public T GetService<T> () where T: class {
  if (_map.ContainsKey(typeof(T))) return _map[typeof(T)] as T;
  else throw new ApplicationException("The type " + typeof(T).FullName + " is not registered in the container");
 }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

A continuación, podemos escribir un pequeño programa que crea un contenedor, muestra los tipos y luego solicita un servicio. Nuevamente, un ejemplo simple y compacto, pero imagine cómo se vería en una aplicación mucho más grande:

public class SimpleDIContainer {  
 Dictionary <Type, object> _map;
 public SimpleDIContainer() {
   _map = new Dictionary < Type, object > ();
  } 

 /// <summary> 
 ///       ,    . 
/// </summary> 
/// <typeparam name="TIn">The interface type</typeparam> 
/// <typeparam name="TOut">The implementation type</typeparam> 
/// <param name="args">Optional arguments for the creation of the implementation type.</param> 
public void Map <TIn, TOut> (params object[] args) {  
   if (!_map.ContainsKey(typeof(TIn))) {
    object instance = Activator.CreateInstance(typeof(TOut), args);
    _map[typeof(TIn)] = instance;
   }
  } 

/// <summary> 
///  ,  T 
/// </summary> 
/// <typeparam name="T">The interface type</typeparam>
 public T GetService <T> () where T: class {
  if (_map.ContainsKey(typeof(T))) return _map[typeof(T)] as T;
  else throw new ApplicationException("The type " + typeof(T).FullName + " is not registered in the container");
 }
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Recomiendo seguir este patrón al agregar nuevas dependencias a su proyecto. A medida que su proyecto crezca en tamaño, verá por sí mismo lo fácil que es administrar componentes poco acoplados. Se gana una flexibilidad considerable y, en última instancia, el proyecto en sí es mucho más fácil de mantener, modificar y adaptar a las nuevas condiciones.