¿Los marcos de inyección de dependencia representan un riesgo de dependencia?

13

He estado refactorizando un sistema existente para usar la inyección de dependencia, y ese trabajo ha ido bien.

Después de un tiempo, noté que una gran cantidad de bibliotecas internas se volvieron dependientes del marco DI que usé. Como resultado, todo el proyecto ahora depende de este marco de terceros.

Vi una ironía en el desacoplamiento de todas las dependencias al hacerlas dependientes de una biblioteca compartida.

Mi primera reacción fue crear una biblioteca de envoltura alrededor del marco de dependencia. Por lo tanto, podría reemplazar este marco si es necesario. Luego de estimar el trabajo involucrado, me di cuenta de que la API resultante sería similar al marco existente y, por lo tanto, dificultaría su reemplazo. Así que abandoné la idea.

Mi preocupación es que el marco DI que estoy usando se vuelve obsoleto o necesita reemplazo.

¿Existe un patrón de desarrollo cuando se trabaja con DI que reduce el acoplamiento entre un proyecto y el marco DI?

    
pregunta cgTag 15.06.2014 - 17:09

3 respuestas

8

Usted tiene toda la razón: el uso de un marco DI probablemente hará que su código dependa de eso. En realidad, eso es demasiado sorprendente, ya que esto suele ser cierto para todos los demás marcos o bibliotecas de bases, especialmente cuando esa biblioteca es compatible con su proyecto con algunas características genéricas utilizadas en cualquier lugar del código. Por ejemplo, cuando decide utilizar un determinado marco de UI o web, esta decisión es difícil de cambiar después, tan pronto como haya creado una cierta cantidad de código basado en esa biblioteca. Cuando decide utilizar una clase específica (tal vez no estándar) String , no puede cambiar esa decisión fácilmente más adelante. Dicha decisión es arquitectónica, es como elegir un determinado lenguaje de programación e intentar cambiar esa decisión después de haber escrito > 100K líneas de código.

El hecho de que todo su código dependa de cierto marco puede no ser un problema siempre que haga lo que usted espera de él, y siempre que se mantenga adecuadamente. Pero puede convertirse en un problema si ese no es el caso. Hay algunas estrategias para lidiar con esa situación:

  • elija un marco de un proveedor en el que tenga fe en que pueda ofrecerle actualizaciones y nuevos lanzamientos en los próximos años

  • elija un marco de código abierto que tenga pocas líneas de código (y una licencia adecuada), para que pueda realizar cualquier mantenimiento por su cuenta, dado que el proveedor desaparece del mercado

  • escribe tu propio marco

  • viva con la situación mientras el proveedor esté disponible, y cuando realmente desaparezca, elija un marco diferente e intente crear un adaptador que emule al antiguo marco utilizando el nuevo

La idea de crear una biblioteca de envoltura de antemano no es nueva en absoluto, pero rara vez he visto que funcione, ya que tendrías que hacer suposiciones para una situación futura en la que no sabes si te afectará o cuándo. , y cómo será el "nuevo" marco. Por otro lado, hace algunos años intercambiamos con éxito un marco de IU completo en un proyecto C ++ con ~ 120K de líneas de código aplicando la estrategia de adaptador que mencioné anteriormente.

    
respondido por el Doc Brown 15.06.2014 - 22:55
19

La inyección del constructor ordinario no requiere un marco en absoluto. Lo único que pierde es la capacidad de centralizar sus dependencias en un archivo de configuración.

Los contenedores DI son un patrón de "software empresarial", utilizado cuando el gráfico de objetos es muy grande y complejo. Sospecho que el 95% de las aplicaciones no lo requieren.

    
respondido por el Robert Harvey 15.06.2014 - 22:40
0

No creo que los marcos DI puedan volverse obsoletos en el corto plazo. ¿Qué debería pasar para que sea obsoleto?

  • ¿Una invención de un patrón nuevo e inteligente tal vez? Sin embargo, debería parecer que requeriría cambios mucho mayores en el código.
  • ¿Un cambio en el idioma tal vez? Peor aún.

Yo diría que la DI actual es lo suficientemente madura y no estoy al tanto de lo que está sucediendo allí. No ha especificado su idioma, por lo que, al hablar de Guice , es bastante discreto y funciona con las anotaciones estándar de Java. (También usa el suyo para cosas no estandarizadas, pero rara vez lo necesita). Es de código abierto, ampliamente utilizado y con licencia Apache. ¿Cuál podría ser el problema?

Estoy bastante seguro de que cambiar el marco de DI sería mucho más fácil que cambiar cualquier otra biblioteca (por ejemplo, un cambio en la interfaz de usuario significa mucho más trabajo).

    
respondido por el maaartinus 15.06.2014 - 23:01

Lea otras preguntas en las etiquetas