¿Por qué considero a Symfony el mejor framework para PHP?

Hola a todos. En esta ocasión voy a escribir mi primer artículo en la vida donde contaré cuáles son los motivos por los que ocupo una de las herramientas más usadas en el mercado de la tecnología/desarrollo y trataré de explicar cuáles son los componentes que más disfruto utilizar y los que me parecen lo mejor a desear para un desarrollo. Ahí te va.

Hoy por hoy la demanda en tecnología dirige a los desarrolladores a escribir aplicaciones que sean más flexibles para poder ajustarse a las nuevas necesidades en el menor tiempo posible, esto quizás no depende de un lenguaje de programación en específico o un framework para su desarrollo sino de patrones de diseño per se. Teniendo eso en mente Symfony ha permitido a lo largo de sus últimas versiones (comencé a utilizarlo cuando existía la versión 2.7) desarrollar aplicaciones con un alto grado de productividad, teniendo en cuenta que basado en comandos se pueden realizar acciones que normalmente se tendrían que hacer manualmente:

• Crear una base de datos
• Crear una tabla en la base de datos
• Agregar relaciones entre tablas de base de datos (teniendo en cuenta que esto es heredado de la dependencia de un paquete conocido: Doctrine)
• Crear CRUD’s basados en tablas de bases de datos (en caso de que se ocupe un RESTFul API se tendrán que hacer algunos ajustes puesto que por defecto se crean vistas con Twig)
• Crear pruebas automáticas individuales y funcionales a través de PHPUnit

Entre las tareas que se pueden crear a través de comandos que existen gratis una vez que se hace la instalación del proyecto, existen otras grandes bondades que vienen incluidas en los paquetes de instalación del framework (o que en la versión actual del proyecto se instalan individualmente), desde un control de rutas/url’s/endpoints muy potentes que permiten incluso agregar expresiones regulares para garantizar que las llamadas se ejecutarán como el desarrollador espera, un paquete de seguridad que permite no sólo autenticar a los usuarios sino también tener control de aquellas cosas a las que tienen acceso, medios para tener control sobre flujos que se deben ejecutar en cierto orden en específico (Workflow), hasta, debo decir que me parece de las cosas que más hay que destacar, un control de inyección de dependencias que hacen que la vida del desarrollador sea más simple, permitiendo encapsular lógica que puede ser compartida en cualquier medio para la ejecución de la aplicación (a través de la internet vía HTTP o como un recurso en línea de comando, etc.).

A partir de aquí en adelante quisiera ser muy puntual con algunos detalles que quisiera destacar sobre el framework y me voy a permitir iniciar por el conocido “logging”:

La forma en la que Symfony usa el logging está basado en un standard, para comenzar, lo cual permite que la interacción con lo que uno quiere escribir en disco esté limitado a el ambiente en el que se está trabajando:

• Mensajes de errores críticos
• Mensajes de errores
• Mensajes informativos
• Mensajes de alertas o emergencias.

Por defecto el logging se escribe en disco, sin embargo el desarrollador tiene la facultad de decidir en qué lugar desea que se almacene el archivo en el que se estarán escribiendo los mensajes. Así mismo existen configuraciones adicionales que se pueden agregar, partiendo de agregar loggers distintos al que se usa por defecto y asignarles nombres específicos para diferenciarlos (desacoplamiento), realizar envío de emails cuando éste sea especificado, incluso existe la posibilidad de hacer una llamada a un endpoint con el mensaje producido.

De este manera el desarrollador tiene la facultad de revisar cómo se está ejecutando cada uno de los flujos que existen en la aplicación, partiendo de los mensajes que se escriben por defecto (y que pueden ser evitados también, sí, pueden ser evitados) hasta los que se escriben individualmente dependiendo las necesidades del desarrollar.

Ahora quiero hablar sobre algo que disfruto mucho usar y me parece uno de las mejores características del framework: eventos.

¿Y si quisiéramos escribir un filtro para saber si el origen de las peticiones es de nuestro dominio?, ¿si quisiéramos realizar acciones diversas tales como enviar notificaciones o emails cuando un nuevo usuario es registrado?, sería sencillo escribir una clase que ejecute ambas responsabilidades, sin embargo el código dejaría de ser legible en el momento en el que esas dos actividades se conviertan en tres actividades, en n actividades, teniendo en cuenta que compartir una clase para dos responsabilidades distintas como enviar un mensaje a un servicio de notificaciones y mandar un email juntas ya pueden tener ciertas complicaciones, a medida que la lógica crece, encontrar un problema o tratar de agregar una tarea nueva se convierte en algo difícil.

A través de eventos, Symfony permite de una manera elegante poder ejecutar n tareas basadas en una acción: en el ejemplo anterior, un registro de un nuevo usuario; permitiéndonos encapsular lógica específica sin tener que acumularla en un único lugar.

Una vez que un evento es disparado, Symfony se encarga de entregar el mensaje de la acción que detonó el evento a todos aquellas tareas que estén interesados en realizar actividades. De esta forma Symfony permite tener un motor de publicadores/suscriptores donde uno tiene la facultad de lanzar todos los eventos que se ocupen, al mismo tiempo permite tener todos los suscriptores que nuestras aplicaciones requieran y para terminar, de las cosas que personalmente más me gustan, fomenta el desacoplamiento de tareas/lógica de negocio como buena práctica, lo cual orienta el desarrollo a ser tan extensible y flexible como éste lo requiera.

De los muchas virtudes que considero que Symfony tiene consigo, creo que esta es una de las más complicadas y es de las características que más me gustan: inyección de dependencias.

En primer lugar, para poder hablar de la inyección de dependencias en PHP, existe un estándar que todos los frameworks/librerías deberían implementar. En el caso particular de Symfony, hace una implementación del estándar en algo que llama Contenedor de Servicios. A través de la inyección de dependencias, el desarrollo se vuelve más eficiente al tener un lugar centralizado para obtener dependencias, entre las que se destacan la conexión a la base de datos, el logging, el despachador de eventos, entre otros, además de todos aquellos objetos que el programador defina como partes que se pueden reutilizar a lo largo de todo el proyecto.

Pasando un poco al funcionamiento, cuando Symfony recibe una petición o se manda a llamar a un comando por consola, se encarga de cargar todos las dependencias que pueden ser inyectadas, posteriormente busca los objetos que a través del ciclo de vida de la ejecución de la aplicación van a ser ejecutados y verifica si existe alguna dependencia que proveer y en caso tener declarada alguna dependencia, Symfony se encargará de inyectarla sí y sólo sí la dependencia es conocida, en otro caso arroja una excepción donde nos informa que la dependencia que está tratando de ser inyectada no es conocida.

Para que los programadores sepamos con qué dependencias contamos, Symfony cuenta con un comando donde enlista todos aquellos objetos que pueden ser declarados para ser inyectados en la ejecución de la aplicación.

Me he tomado la libertad de únicamente redactar acerca de aquellos componentes que me parecen parte de las principales bondades que tenemos los desarrolladores para trabajar con este Framework, sin embargo la información al respecto es muy extensa y me parece que esto amerita me dedique a escribir ejemplos de uso de algunos componentes de Symfony, me parece que en primer lugar serán sobre los componentes ya mencionados y si algun lector tiene alguna petición sobre cómo funciona algún otro componente, me pongo de acuerdo para escribir un artículo al respecto detallando la funcionalidad y mostrando con ejemplos el funcionamiento per se.

Saludos.