Usar el container de Symfony2 para implementar Inyeccion de Dependencias

[manuelj555]

Buenas.

La idea es que la v2 de KumbiaPHP, implemente la Inyección de Dependencias correctamente, para así poder tener clases realmente desacopladas y cambiables (De manera sencilla) en todo el framework como tal.

Una herramienta excelente para dicha implementación es el Container de Symfony (no he visto mejor lib), el cual permite registrar clases y sus dependencias, y luego el se encargará de resolver las mismas, quitandonos dichas tareas.

Acá se habla más extensamente del tema:

http://gitnacho.github.io/symfony-docs-es/components/dependency_injection/introduction.html

SOLID

Realmente sus ventajas son muchas, primero nos permite trabajar realmente usando el principio de SOLID al no tener que depender de tantas clases estáticas en el FW, lo cual sabemos, aveces nos complica reescribir y extender las mismas (y más aun con la implementación de namespaces), con un container esto no sería problema alguno.

Inversión de Control

Además, permite que las clases no se deban encargar de la creacion/gestion de otras clases y recursos, sino que es el contenedor el encargado de hacer llegar las dependencias a cada clase.

Extension

Es muy facil agregar/reescribir clases al contenedor, lo que permitirá añadir funcionalidades (Mailer, Log, PDF, XLS, etc...) de manera sencilla en los proyectos, dichas libs no dependerán de clases como la Config::get() para leer parametros de configuracion, ni habrá que configurar las libs manualmente en la App (crear la instancia cada vez que se necesite y configurarle los parametros, o tener que crear una clase Singleton que cree la instancia configurada :-/).

Cambio de Clases

Seria facil cambiar por ejemplo el router a usar, por otro que queramos (algo que no se ha podido implementar actualmente).

Menos dependencias

No dependeriamos de constantes como PRODUCTION o APP_PATH, ya que serian parametros del contenedor, y se podrian facilmente pasar a las clases que registremos en el mismo.

Por ejemplo ahora mismo el nuevo AR depende de la constante APP_PATH para leer la config de conexion a BD, algo que dificulta su uso fuera del contexto del FW.

Esas son algunas de las ventajas que desde mi punto de vista obtendriamos al implementar el componente.

[joanhey]

Hola Manuel,
como ya hablamos por el IRC, después de escribir este issue, la v2 si tendrá inyección de dependencias. Pero las posibilidades de que sea el de symfony son mínimas.
Hay muchos otras libs de DI:
PHP DI, Orno Di, Auryn, Acclimate, ....

Actualmente todo el código de KumbiaPHP es propio, sin depender de ninguna clase de terceros.

[manuelj555]

Se podrian hacer comparaciones entre lo que ofrecen los diferentes Containers existentes, y ver cual puede ser mejor para el FW.

Por otro lado no veo nada de malo en usar herramientas y libs de terceros, más bien esa es la idea que se viene promoviendo en los ultimos tiempos de PHP (composer-autoload, Monolog, ...).

En cuanto a DIC, en mi opinión no existe otra lib tan flexible con el symfony/dependency-injection, ya que es de las muy pocas que cachean (lo cual da una velocidad impresionante), y permiten trabajar con etiquetas, y estas ultimas se puede decir que son una de las cosas más poderosas de la herramienta.

[manuelj555]

Otra posible opcion sería usar Pimple que es más sencillo y liviano:

http://pimple.sensiolabs.org/

Es bastante liviano y hasta existe una implementación para agregarlo como extensión de php.

Para proyectos pequeños es ideal, ahora para proyectos grandes ya es otra cosa, además al no ser cacheado no permite el uso de servicios etiquetados.

Pero creo que implementarlo o usar algún otro es un gran avance :-)

[EBethus]

Estuve revisando ayer esa libs y cuando tenga tiempo voy a probarla en el backend