Contenedores Ioc e idiomas dinámicos (toma 2)

Question

He estado leyendo mucho sobre Inyección de Dependencia, Inversión de Control y contenedores IoC. También programo principalmente en lenguajes dinámicos (PHP en el trabajo, Python en casa). Estas son las cosas que estoy encontrando, pero esto deja muchas lagunas para mí para llenar ya que las piezas de él todos juntos:

• Why are IOC containers unnecessary with dynamic languages?
• Why do I need an IoC container as opposed to straightforward DI code?
• Advantages an IoC container provides beyond simple DI (blog)

Entonces, lo que estoy leyendo es: los contenedores IoC son mucho más importantes en los lenguajes estáticos, porque es mucho más fácil realizar DI en los lenguajes dinámicos. Pero también brindan beneficios mucho más allá de DI, como la administración de dependencias por usted y evitando tener que unir una docena de objetos a mano. Y, por cierto, son complicados, así que no intentes hacerlos tú mismo (pero no existen los buenos para PHP).

Siento que esta información me deja un poco ... estancada. ¿Que hago con esto? Trabajo en una base de código muy grande, con dependencias muy complicadas (y probablemente una gran necesidad de refactorización, pero ese es otro problema paralelo). Hemos hecho muy mal la implementación de DI hasta ahora, y realmente estoy tratando de orientarnos en la dirección correcta. Simplemente parece que no hay nada por ahí en lo que respecta a los lenguajes dinámicos y IoC (o al menos contenedores de IoC).

¿Es mejor que me relacione con las dependencias "a mano" por el momento, y me preocupe por automatizarlo en un contenedor más adelante, después de que tenga un mejor manejo de los principios? ¿Vale la pena implementar mi propio contenedor de IoC? ¿O el beneficio simplemente no vale la pena el costo en PHP?

Answer 1

Martin Fowler escribió este artículo que es más o menos una biblia para la inversión de control y la inyección de dependencia. Explica cómo implementar un contenedor IoC y analiza los méritos de los diferentes mecanismos de inyección. http://martinfowler.com/articles/injection.html

Cualquiera que sea el idioma que utilice, las "dependencias de encadenamiento manual" no son escalables. Será difícil de mantener, porque otros desarrolladores probablemente no saben dónde se lleva a cabo todo el tendido a mano, de modo que cuando cambien algo, es posible que no cambien lo correcto. Por el contrario, poner todo esto en un solo lugar hará que los cambios futuros sean mucho más fáciles de implementar. IoC ayuda a minimizar el código repetitivo y garantiza una separación de preocupaciones y una arquitectura de aplicación consistente.

Por otro lado, parece que tiene una aplicación de funcionamiento bastante grande en sus manos, y a menos que tenga mucho tiempo, si no está rota, podría no ser necesario repararla.

Answer 2

Para PHP, pruebe Symfony Dependency Injection. Es (supuestamente, tengo muy poca experiencia para validar eso) en función de cómo funciona Java Spring, pero también usa mucha 'magia' de PHP. Como resultado, es bastante liviano y fácil de usar, mientras que puede hacer bastante.

Answer 3

Si no desea tener un DIC overdesigned pero que ofrece todo lo que necesita de una manera muy compacta, pruebe este: Bucket (https://github.com/troelskn/bucket). Un contenedor DI no necesita más. Al lado de Symfony uno se utiliza a menudo de una manera muy peligrosa, como un localizador de servicios (el mejor estado global alias).

Answer 4

Si cree que su IoC es/puede ser más liviano, entonces, qué otros marcos ya tienen y si tiene tiempo suficiente para desarrollarlo, cree el suyo. Yo personalmente uso IoC en mi framework MVC solo para vincular View al Controller. Administro la vista y sus parámetros desde un registro (una matriz asociativa de estructura estandarizada).Los modelos se manejan como servicios externos. También encontré IoC y DI por primera vez en Java, así que traté de tomar lo mejor de ambos lenguajes (Java y PHP) cuando construí el mío. Por supuesto, no vincula nada con nada, pero no necesito eso para mi caso, por lo que es posible que tampoco.

IoC es importante para proporcionar flexibilidad en el tiempo pero ¿cuánta flexibilidad? ¿Trabajas con muchos componentes externos? ¿Trabajas con plugins y objetos estándar? PHP no es java, no tiene ese saco de jarras y bibliotecas tan bien desarrollado listo para implementar en cualquier momento simplemente al cargarlo y reemplazar una directiva en un XML para señalarlo, piense en eso.

He encontrado una excelente implementación de IoC en un software de código abierto excepcional llamado Alfresco (Sistema de gestión de documentos). Es un producto que reúne JSF, Spring, Hibernate y la plantilla Freemarker, pero como he dicho es un producto destinado a encajar en miles de modelos de negocio, es más como una plataforma altamente avanzada destinada a ser modificada sin fin, por lo que necesita ser altamente flexible

Si está desarrollando una aplicación específica, diseñada para servir un modelo de negocio y solo unos pocos clientes, entonces sumergirse en la flor de IoC hará las cosas más difíciles en lugar de más simples.

Einstein dijo que las cosas deben ser simples, pero no más simples de lo que son.

Answer 5

Primero corrige tus problemas de dependencia. Si utiliza un Contenedor de IoC como una bolsa que se ocupa de sus dependencias, le morderá muy duro, no muy lejos en la línea.

Los contenedores IoC deberían proporcionarle un API/Vocabulary para hablar sobre la arquitectura del sistema.

La inyección de dependencia lo lleva a utilizar clases desacopladas más pequeñas que actúan como bloques de construcción para los subsistemas. Esto es bueno ya que le permite probar sus bloques de construcción en forma aislada y razonar sobre ellos más fácilmente. (Puede pensar en ellos como componentes electrónicos en un circuito)

Los Contenedores de IoC deberían darle una forma de expresar claramente la composición de estos componentes básicos. (el diagrama de cableado une los componentes)

Tener esta separación también le permite comenzar a pensar en la vida útil de sus subsistemas ... cuándo usar fábricas, registros, cómo pasar mensajes por el sistema sin introducir acoplamientos ... etc.

El objetivo de IOC es darle un lugar para declarar explícitamente toda esta lógica, no para resolverla mágicamente por usted.

Espero que esto ayude.