Hola a todos Quiero confesar ante ti y contarte un poco sobre cómo me siento cuando me desarrolle en Laravel. No, no lo pienses, adoro este marco y estoy increíblemente agradecido con el equipo que lo creó y lo apoya, hacen un trabajo extremadamente bueno y, en mi opinión, Laravel es la mejor continuación de Symfony, no menos querido por mí.
Me encanta el código tonto. Es tonto en el sentido de que incluso después de 10 años, si el cliente le pide que realice cambios, puede hacerlo sin profundizar en toda la lógica, incluso después de estar después de una fiesta corporativa el viernes, sin romper nada en el código anterior. Y tonto en el sentido de que no necesitas hacer ningún esfuerzo cognitivo para entenderlo. Pero hay una solución arquitectónica en Laravel Eloquent ORM que me hace llorar. Interesante? Ven debajo del gato.
Las personas inteligentes nos han inventado todo hace mucho tiempo: OOP, Patrones de diseño, SOLID, DDD y otras palabras aterradoras que te asustan tanto al principio, y luego las aplicas de una vez.
Estos me gustan Laravel y Symfony. Le permiten escribir el código más tonto y seguro desde el primer momento. Si Cada uno de ellos tiene sus inconvenientes ... Pero en Laravel hay uno que me molesta más. Esto está utilizando el patrón de grabación activa (AR) para trabajar con modelos.
Para empezar, un poco sobre este patrón. ¿De qué se trata todo esto? Para comprenderlo, debe dirigirse al padre de esta obra de diseño de aplicaciones: el patrón de repositorio. Este patrón es una colección. Una colección de entidades (Entidad) que puede recuperar, modificar, guardar, eliminar, en general, administrarlas en una ubicación de almacenamiento abstracta. En 90 del 100 por ciento de los casos, esta ubicación de almacenamiento es una variedad de bases de datos. Pero puede haber un sistema de archivos y algún tipo de caché e incluso una API externa.
Este enfoque es totalmente coherente con el principio de responsabilidad compartida y el enfoque DDD. Además, gracias a este enfoque, se implementa una conectividad débil: no nos importa cómo se almacena exactamente la aplicación, trabajamos con Entity cuando queremos trabajar directamente con la representación de datos de los objetos y con Repository cuando necesitamos interactuar con el repositorio.
Pero Laravel decidió seguir el camino del uso de AR, que es indudablemente genial e increíblemente conveniente cuando necesita hacer un prototipo rápido, pero se convierte en un dolor de cabeza increíble cuando necesita interactuar con varias fuentes de datos y operar con ellas dentro del sistema.
AR es un patrón que asigna Entidad y Repositorio en un Modelo. Es decir, un objeto se convierte en una representación de un registro particular en la base de datos. Y ... que? ¿A qué conduce esto y por qué es tan molesto?
Primero, violamos el mismo principio de responsabilidad compartida: la lógica de trabajar con el repositorio en un lugar y la lógica de trabajar con una entidad en otro. Esto es importante, porque en el marco de mi sistema no quiero transferir una línea de la base de datos en la representación del objeto a través de la cadena de llamadas. Quiero pasar el modelo. No debería importarme cómo resulta, cambia y persiste. Necesito tener esos métodos que le permitan interactuar solo con el modelo y no con las filas de la base de datos.
En segundo lugar, no podemos (como consecuencia del hecho de que la capa Persistente, la capa de almacenamiento, está conectada con la capa de entidad), simplemente cambiar la ubicación de almacenamiento del modelo. Sí, podemos hacer esto en la configuración, cambiándolo de inmediato para todos, dentro de las bases de datos compatibles. O cambie solo para un modelo específico (con todo esto, no eliminamos ningún método de creación de consultas, porque no puede deshacerse de los métodos de la clase base) y se encuentra con una tonelada de errores probables en el código o, Dios no lo quiera, si alguien más apoyará (y esto sucede todo el tiempo).
En tercer lugar. Quiero probar mis entidades. Quiero condenarlo para asegurarme de que los cambios que realice no rompan mi lógica comercial. Y, como muestra la práctica, en el caso de AR no se puede hacer esto, ¡porque se ha violado el principio diabólico de la responsabilidad individual! Aunque aquí estoy un poco falso. Es posible probar modelos, solo ... Un poco complicado.
Sin embargo, es imposible no decir acerca de las ventajas de este patrón. Aunque todo su plus es que es "rápido, simple, sin dudarlo". Al fusionar dos patrones que tienen una lógica cercana a sus acciones y se usan constantemente juntos, obtuvimos una herramienta conveniente que reduce ligeramente la cantidad de código (en la dirección de la complejidad, ¿recordamos el "código tonto"?). También le permite deshacerse de problemas innecesarios en la etapa de formación de MVP, que es obligatorio (la práctica muestra que esto rara vez sucede, pero aún así) está planeado reescribir. Esto le permite cambiar los pensamientos de la pregunta "cómo lo hacemos" a la pregunta "qué hacemos", es decir, deshacerse de las preguntas innecesarias sobre tecnologías y pasar a la lógica empresarial.
¿A qué conclusión he llegado a lo largo de los años usando el ORM elocuente de Laravel? ¿Registro activo del mal en la carne? No, esta es la herramienta más genial para algunas situaciones, especialmente para la etapa en la que está escribiendo una aplicación simple o un prototipo de dicha aplicación. Pero esto es algo imposible de trabajar cuando su aplicación crece y tiene que trabajar con una gran cantidad de fuentes de datos, escribir código con una cobertura de prueba del 100% y comienzan grandes problemas.
Sí, se están inventando nuevas fichas (¿ Trucker ?), Pero sigamos haciendo trucos. Pero aún así quiero un poco más de libertad del marco, ¡especialmente porque es tan bueno para tantos!