Me parece que no pasa por solo usar un patrón de moda para poder testear. Sino la cuestión está en conseguir la "inversión de control" que suele ser importante en POO para que no exista un acoplamiento fuerte entre las unidades funcionales. De este modo todo el codigo se vuelve rigido queda acoplado a una versión de eloquent por lo cual se vuelve dificil de cambiar o frágil si ocurren cambios en este.
Buen video Victor! Creo que Eloquent es ideal para sacar proyectos chicos y medianos. Pero cuando los proyectos empiezan a crecer, cobra más sentido usar repositorios porque te resuelven más problemas.
No sé, creo que en Laravel no te resuelven más problemas. Aparte del testing, pero como ya he dicho en Laravel priorizo test de feature, el resto sigue atado a Eloquent como tal y tampoco te ayuda si quisieras cambiar la fuente de datos en un futuro.
¿lo decís por el código fuente de tiendanube? Nunca he visto que lo utilicen, creo que ni siquiera Freek en su app oh-dear (la mas grande que he visto en un livecoding) lo usa
@@victorfalcon priorizar los feature test no iría en contra de la pirámide de tests? Por otro lado, si necesitamos cambiar la fuente de datos de un modelo Eloquent a microservicio, ¿no ayudarían tener los repositorios?
@Laravel Tip En cuánto a la pirámide, es como es por algo. Muchos test unitarios porque son fáciles de hacer y de ejecutar y menos funcionales por lo contrario, pero con Laravel nos encontramos que los funcionales son sencillos de hacer, se pueden ejecutar en paralelo (son rápidos) y además aportan más valor. Por eso en Laravel, prefiero hacer funcionales. En cuanto a cambiar la fuente de datos, depende. Si en tus repositorios estás devolviendo un modelo eloquent, que es lo habitual y es como muestro en el ejemplo. Poco te ayudará tener un repositorio. Por mucho que quieras cambiar el repositorio el resto de tu aplicación esta "atado" a Eloquent.
@@victorfalcon pero test unitarios en paralelo son más rápidos que feature tests en paralelo. Otro punto en contra de Eloquent es que mezcla lógica de negocio con persistencia haciendo que los modelos queden como clases enormes. Con respecto al otro punto, no es lo habitual devolver un modelo eloquent. No sería una implementación correcta que un repositorio devuelva un modelo de eloquent. Igualmente entiendo tu punto y como dije en mi blog, todo depende del proyecto.
Claro, en mi experiencia lo mejor es seguir el patrón que te propone el framework y los scopes entran en él. Lo que no recomiendo nada es poner toda la lógica en el controlador, que eso se hace mucho... 😄
@@victorfalcon ahi tienes la razon. Y para ese caso de no poner toda la logica en el controlador, que me recomiendas? En los scope solo deberia ir consultas ditectas sin logica,
Yo estoy empezando con laravel, siempre he trabajado con mvc artesanal. Pero lo que veo es que me lleva a ponerle gran logica en el controlador...que me recomendarias para que la logica no este toda en el controlador?
@@alvaroaliaga7892 usa controladores invocables así no tienes controladores que hacen 3 millones cosas y si usas vistas HTML combinarlo con View Composition te ayudará a lograrlo
El patrón repositorio bien aplicado debería de retornar interfaces de un objeto y no referencias directas a la implementación, es decir, no retornes de un findById de UserRepository un User retorna en su lugar un UserInterface eso te permite incluso falsear rápidamente en los test unitarios dicho objeto que viene por respuesta de un repo, por otra parte para evitar atarte al framework puedes usar objetos propios de dominio que representen tu negocio y modelos de persistencia, es más largo pero evitas acople con Eloquent así como la lógica de un controlador llevarla a servicios o casos de uso y no hacer 7 millones de cosa en un método de un controlador
Ese tema light no deja leer muy bien el código
Me parece que no pasa por solo usar un patrón de moda para poder testear. Sino la cuestión está en conseguir la "inversión de control" que suele ser importante en POO para que no exista un acoplamiento fuerte entre las unidades funcionales. De este modo todo el codigo se vuelve rigido queda acoplado a una versión de eloquent por lo cual se vuelve dificil de cambiar o frágil si ocurren cambios en este.
Buen video Victor! Creo que Eloquent es ideal para sacar proyectos chicos y medianos. Pero cuando los proyectos empiezan a crecer, cobra más sentido usar repositorios porque te resuelven más problemas.
No sé, creo que en Laravel no te resuelven más problemas. Aparte del testing, pero como ya he dicho en Laravel priorizo test de feature, el resto sigue atado a Eloquent como tal y tampoco te ayuda si quisieras cambiar la fuente de datos en un futuro.
¿lo decís por el código fuente de tiendanube? Nunca he visto que lo utilicen, creo que ni siquiera Freek en su app oh-dear (la mas grande que he visto en un livecoding) lo usa
@@victorfalcon priorizar los feature test no iría en contra de la pirámide de tests?
Por otro lado, si necesitamos cambiar la fuente de datos de un modelo Eloquent a microservicio, ¿no ayudarían tener los repositorios?
@Laravel Tip En cuánto a la pirámide, es como es por algo. Muchos test unitarios porque son fáciles de hacer y de ejecutar y menos funcionales por lo contrario, pero con Laravel nos encontramos que los funcionales son sencillos de hacer, se pueden ejecutar en paralelo (son rápidos) y además aportan más valor. Por eso en Laravel, prefiero hacer funcionales.
En cuanto a cambiar la fuente de datos, depende. Si en tus repositorios estás devolviendo un modelo eloquent, que es lo habitual y es como muestro en el ejemplo. Poco te ayudará tener un repositorio. Por mucho que quieras cambiar el repositorio el resto de tu aplicación esta "atado" a Eloquent.
@@victorfalcon pero test unitarios en paralelo son más rápidos que feature tests en paralelo.
Otro punto en contra de Eloquent es que mezcla lógica de negocio con persistencia haciendo que los modelos queden como clases enormes.
Con respecto al otro punto, no es lo habitual devolver un modelo eloquent. No sería una implementación correcta que un repositorio devuelva un modelo de eloquent.
Igualmente entiendo tu punto y como dije en mi blog, todo depende del proyecto.
Muy bueno y bien explicado!! Gran video, muchas gracias!
Muy buen aporte victor. Y usar active record con scopes y accesores? es buena combinacion?
Claro, en mi experiencia lo mejor es seguir el patrón que te propone el framework y los scopes entran en él. Lo que no recomiendo nada es poner toda la lógica en el controlador, que eso se hace mucho... 😄
@@victorfalcon ahi tienes la razon. Y para ese caso de no poner toda la logica en el controlador, que me recomiendas? En los scope solo deberia ir consultas ditectas sin logica,
Yo estoy empezando con laravel, siempre he trabajado con mvc artesanal. Pero lo que veo es que me lleva a ponerle gran logica en el controlador...que me recomendarias para que la logica no este toda en el controlador?
@@alvaroaliaga7892 mírate este vídeo ruclips.net/video/shlAZcXu7WI/видео.html
@@alvaroaliaga7892 usa controladores invocables así no tienes controladores que hacen 3 millones cosas y si usas vistas HTML combinarlo con View Composition te ayudará a lograrlo
El patrón repositorio bien aplicado debería de retornar interfaces de un objeto y no referencias directas a la implementación, es decir, no retornes de un findById de UserRepository un User retorna en su lugar un UserInterface eso te permite incluso falsear rápidamente en los test unitarios dicho objeto que viene por respuesta de un repo, por otra parte para evitar atarte al framework puedes usar objetos propios de dominio que representen tu negocio y modelos de persistencia, es más largo pero evitas acople con Eloquent así como la lógica de un controlador llevarla a servicios o casos de uso y no hacer 7 millones de cosa en un método de un controlador
no entiendo nada
Mockear = Falsear