¿Debo usar inyección de dependencia en mi proyecto php?

Question

Recientemente he aprendido los méritos de la inyección de dependencia, pero me pregunto si debería usarlo en mi proyecto, ya que ni siquiera necesito un mvc completo. Ahora que lo estoy usando, me estoy dando cuenta de la sobrecarga adicional en cada página que escribo. Por ejemplo ...

require_once '../../include/session.class.php'; 
    require_once '../../include/db.class.php'; 
    require_once '../../include/account.class.php'; 

    $objSession = new Session(); 
    $objDb  = new Db(); 
    $objAccount = new Account($objSession, $objDb); 

account.class.php

class Account { 
    ... 
    public function __construct(Session $objSession, Db $objDb) { 
     $this->session = $objSession; 
     $this->db = $objDb; 
    } 
} 

... la clase cuenta siempre debe tener Db y sesión y sólo tendrá nunca una clase de cada uno. Así que mi pregunta es, debo utilizar DI en una situación como esta o debo usar ...

account.class.php

require_once '../../include/session.class.php'; 
require_once '../../include/db.class.php'; 

class Account { 
    ... 
    public function __construct() { 
     $this->session = new Session(); 
     $this->db = new Db(); 
    } 
} 

...?

Answer 1

Dependency Injection no tiene nada que ver con MVC. Es realmente bueno para hacer que las pruebas unitarias sean más fáciles de escribir y, en última instancia, descubrí que realmente me hace pensar en los recursos que estoy usando y en si esa implementación debería usar ese recurso.

Personalmente, no veo el daño al crear el objeto inyectado, ¿así que tienes un par de líneas donde tienes que crear un objeto? Le dice al usuario mucho más sobre lo que está pasando. Prefiero tener claridad en comparación con la magia.

Personalmente, creo que la mayoría del desorden en el código proviene de las declaraciones require. Yo diría que un autocargador resolvería parte de ese problema.

Realmente disfruté este Google Clean Code Talk on DI. Me ayudó a captar un poco mejor el concepto y sus beneficios.

Answer 2

Los contenedores de inyección de dependencia se inventaron para resolver este problema. Considere:

$account = DependencyInjectionContainer::build('Account'); 

La clase DependencyInjectionContainer se ocuparía de la inyección:

public static function build($class) { 
    switch ($class) { 
     case 'Account': 
      $session = new Session(); 
      $db = new Db(); 
      return new Account($session, $db); 

     // ... 
    } 
} 

Answer 3

Usted ha leído acerca de los méritos de la inyección de dependencia. ¿Por qué comenzaste a usarlo?

¿Fue debido a la capacidad de cambiar esas dependencias particulares para pruebas o entornos diferentes? ¿Fue para aislar y hacer explícito el orden de una cadena circular de dependencias?

Supongamos, por ejemplo, que fue el deseo de inyectar diferentes clases para fines de prueba (el mérito de DI que me hizo usarlo). ¿Cómo manejas eso sin DI?

Mire la clase de su cuenta. Puede modificar el constructor con una verificación if en algún predicado testMode(), o puede modificar los constructores Db y Session, o podría posiblemente cambiar un archivo de configuración. Cualquiera que sea la solución sin DI que elija, ¿está de acuerdo con eso? ¿Qué pasa con otras dependencias (correo electrónico, registrador, etc.)? ¿Tiene alguna interfaz con sistemas externos que debería simular para probar?

De todos modos, la respuesta podría ser que está satisfecho sin la solución DI y que su aplicación es lo suficientemente pequeña como para administrarla sin ella.Pero es importante hacerse la pregunta de todos modos.

De manera similar, aplique esa misma línea de preguntas a los otros méritos de DI que lo motivaron a comenzar a usarlo.

Por cierto, ¿tiene una instancia de Db en Cuenta y otra en cada una de sus otras clases? ¿Podrías tener solo una instancia? DI ayuda con eso. Puede tener clases singleton sin codificarlas realmente como singleton inyectando siempre la misma instancia.

Por curiosidad, ¿por qué está haciendo su propia inyección de dependencia en lugar de usar una biblioteca DI? La mitad del beneficio del uso de DI es que es limpiamente abstraída por las implementaciones de otras personas. Solo escriba el código que necesita y deje que las bibliotecas se encarguen de hacer la inyección por usted. Esto es similar a la sugerencia de drrcknlsn, pero sin tener que escribir la aplicación real de la clase DependencyInjectionContainer:

$ representan = DependencyInjectionContainer :: acumulación ('Cuenta');

y atornille el resto.

Una buena biblioteca DI debería ver el constructor para Account, darse cuenta de que necesita un Db y una Session, y marchar hacia la cadena de constructores (en este caso, termina allí ya que ambos tienen constructores vacíos). Eso se traduce en tener la misma cantidad de código que el caso sin DI (más los argumentos para el constructor, menos las llamadas a los constructores internos, pero no más basura en la parte superior), con los beneficios que te trajeron a DI en primer lugar.