¿La inyección de dependencia del pobre es una buena forma de introducir la capacidad de prueba en una aplicación heredada?

El año pasado, creé un nuevo sistema usando Inyección de dependencia y un contenedor de COI. ¡Esto me enseñó mucho sobre DI!

Sin embargo, incluso después de aprender los conceptos y patrones adecuados, considero que es un desafío desacoplar el código e introducir un contenedor IOC en una aplicación heredada. La aplicación es lo suficientemente grande como para que una implementación real sea abrumadora. Incluso si se entendió el valor y se concedió el tiempo. ¿A quién se le concede tiempo para algo como esto?

¡El objetivo, por supuesto, es llevar las pruebas unitarias a la lógica comercial!
Lógica empresarial que se entrelaza con llamadas de base de datos que evitan las pruebas.

He leído los artículos y entiendo los peligros de la inyección de dependencia del pobre como se describe en este artículo de Los Techies . Entiendo que realmente no desacopla nada.
Entiendo que puede involucrar mucha refactorización de todo el sistema ya que las implementaciones requieren nuevas dependencias. No consideraría usarlo en un nuevo proyecto con ninguna cantidad de tamaño.

Pregunta: ¿Está bien usar la DI de Poor Man para introducir la capacidad de prueba en una aplicación heredada y comenzar a rodar?

Además, ¿está utilizando la DI de Poor Man como un enfoque de base para la verdadera inyección de dependencia una forma valiosa de educar sobre la necesidad y los beneficios del principio?

¿Puede refactorizar un método que tiene una dependencia de llamada a la base de datos y abstraer esa llamada detrás de una interfaz? Simplemente tener esa abstracción haría que ese método sea comprobable ya que una implementación simulada podría pasarse a través de una sobrecarga del constructor.

En el futuro, una vez que el esfuerzo gane simpatizantes, el proyecto podría actualizarse para implementar un contenedor de COI y los constructores estarían allí para captar las abstracciones.

La crítica sobre la inyección de Poor Man en NerdDinner tiene menos que ver con si usas o no un contenedor DI que con la configuración correcta de tus clases.

En el artículo, afirman que

public class SearchController : Controller {

    IDinnerRepository dinnerRepository;

    public SearchController() : this(new DinnerRepository()) { }

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

es incorrecto porque, si bien el primer constructor proporciona un mecanismo de respaldo conveniente para construir la clase, también crea una dependencia estrechamente vinculada a DinnerRepository.

El remedio correcto, por supuesto, no es, como sugiere Los Techies, agregar un contenedor DI, sino más bien eliminar al constructor ofensor.

public class SearchController : Controller 
{
    IDinnerRepository dinnerRepository;

    public SearchController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }
}

La clase restante ahora tiene sus dependencias correctamente invertidas. Ahora eres libre de inyectar esas dependencias como quieras.

Aquí haces una suposición falsa sobre lo que es la "DI del pobre".

Crear una clase que tenga un constructor de "atajo" que todavía cree acoplamiento no es la DI del pobre.

No usar un contenedor, y crear todas las inyecciones y mapeos manualmente, es la DI del pobre.

El término "DI del pobre" suena como algo malo. Por esa razón, el término "DI pura" se recomienda en estos días, ya que suena más positivo y en realidad describe con mayor precisión el proceso.

No solo es absolutamente correcto usar la DI pura / pobre del pobre para introducir la DI en una aplicación existente, sino que también es una forma válida de usar la DI para muchas aplicaciones nuevas. Y como usted dice, todos deberían usar DI puro en al menos un proyecto para comprender realmente cómo funciona DI, antes de asumir la responsabilidad de la "magia" de un contenedor de IoC.

Los cambios de paragidm en equipos / bases de código heredados son extremadamente riesgosos:

En cualquier momento en que usted sugiere "mejoras" a código heredado y hay un "legado" programadores en el equipo, que están diciendo a todos que "lo hicieron mal" y te conviertes en el enemigo para el resto de su / su tiempo con la empresa.

Usar un DI Framework como un martillo para romper todas las uñas solo hará que el código heredado sea peor que mejor en todos los casos. También es extremadamente arriesgado personalmente.

Incluso en los casos más limitados, como solo para que pueda usarse en casos de prueba, solo hará que esos casos de prueba sean "no estándar" y el código "extranjero" que, en el mejor de los casos, solo se marcarán @Ignorecuando se rompan o, peor aún, se quejarán constantemente Los programadores heredados con la mayor influencia en la administración y se reescriben "correctamente" con todo este "tiempo perdido en las pruebas unitarias", atribuido únicamente a usted.

La introducción de un marco DI, o incluso el concepto de "DI puro" en una aplicación de línea de negocios, y mucho menos una enorme base de código heredado sin la ayuda de la administración, el equipo y especialmente el patrocinio del desarrollador principal serán la sentencia de muerte para usted social y políticamente en el equipo / empresa. Hacer cosas como esta es extremadamente arriesgado y puede ser un suicidio político de la peor manera.

La inyección de dependencia es una solución que busca un problema.

Cualquier lenguaje con constructores, por definición, utiliza la inyección de dependencia por convención si sabe lo que está haciendo y entiende cómo usar un constructor correctamente, este es un buen diseño.

La inyección de dependencia solo es útil en pequeñas dosis para un rango muy limitado de cosas:

• Cosas que cambian mucho o tienen muchas implementaciones alternativas que están vinculadas estáticamente.

  • Los controladores JDBC son un ejemplo perfecto.
  • Clientes HTTP que pueden variar de una plataforma a otra.
  • Sistemas de registro que varían según la plataforma.

• Sistemas de complementos que tienen complementos configurables que se pueden definir en el código de configuración en su marco y se descubren automáticamente al inicio y se cargan / recargan dinámicamente mientras se ejecuta el programa.