Excelente vídeo, en la universidad nos hicieron utilizar este patrón pero no le ví mucha utilidad ya que era una aplicación pequeña y además ni lo explicaron bien. Solo tengo una pregunta, había visto implementaciones de esto pero con una interface y la verdad no me quedaba muy claro el por qué, y veo que tú tampoco tuviste que hacer una, me podrías explicar por qué?
La interfaz lo que va hacer es definir los metodos que si o si tienen que llevar todos los repositorios que extiendan de esa interfaz entonces vas a tener el extend BaseRepo implement BaseInterface, eso depende ya de cada uno. Lo que te recomiendo que veas es el video del patron decorador que esta en el canal que usa interfaz sobre el repositorio
excelente profe, vengo desarrollando en laravel hace meses, tus videos me han servido bastante. El patron repositorio es genial por la abstraccion de la logica. Pero a veces siento que se pierde esa "magia de laravel" de desarrollar todo mas rapido, ejecutando estas consultas de eloquent en el servicio o clase que necesites. Es decir, necesitar hacer una consulta y tener que crearla en el repositorio y luego usarla, de la otra manera mas "rapida" seria hacer esas consultas con eloquent directamente en la clase. Que opinas al respecto?
Que eso que decis es para un proyecto muy chico, luego si no separas en responsabilidades se vuelve inmanejable y ahí es cuando te vas a demorar más tiempo en rehacer que empezar desde el principio haciendo lo correcto
Muchas gracias por tan maravillosas explicaciones... Lo mejor. Ahora, tengo una duda. ¿Cual es la diferencia entre el patrón Adapter y Repository? Para mi: 1. Ambos sirven como intermediarios, porque con el Adapter también se creo ese intermediario para evitar el acoplamiento.
Me alegro que te haya servido. Ambos son intermediarios pero el repositorio es una capa intermedia entre tu logica y la base de datos abstrayendo lo que se usa para realizar las consultas a la BD, mientras que el adapter es una clase que hace de enlace entre dos clases que no son compatibles. Te dejo el link al video que tengo del patron adapter ruclips.net/video/DEriDJS9IR0/видео.html
Excelente video, tengo una pregunta, como pasaría el UserRepository a través de Métodos genéricos? Es decir de un método que puede recibir tanto UserRepository, como PostRepository o algun otro repositorio ? teniendo en cuenta que cada repositorio implementa métodos específicos? GRACIAS
En que caso necesitarías hacer algo así?, en ese caso me imagino que tendrias un metodo que recibiría un parametro de tipo BaseRepository ya que todos extienden de este
Men una pregunta, si la idea es desacoplarse de Eloquent, por qué el método tiene que instanciar un modelo de Eloquent? por ejemplo en la creación, actualización y eliminación del usuario. Entiendo que se quiera reutilizar el método save() de cada modelo pero en teoría, toda esa lógica no tendría que estar en el UserRepository?
Esta bien lo que decis y acá donde debe entrar otro patrón que es el factory (entre otros) que se encarga de crear las instancias para pasarlo al repository. Ese video tengo pensado hacerlo más adelante
En esencia son lo mismo, son abstracciones usadas para ocultar donde y como se ubican los datos. El DAO mas cerca de la base de datos mientras que el repositorio un poco mas arriba al mismo nivel que el dominio.
La explicación esta buenisima!!, pero veo que todos los métodos de todas las clases son públicos. Esto no deberia ser asi, hay que encapsular logica con private, protected, haciendo uso de herencia. Todo no puede ser publico en una clase, ojo con ese tema. Igual para el ejemplo puntual, de repository, esta muy bien, ya que es solo un ejemplo.
Los invito a sumarse al canal de slack join.slack.com/t/returnespacio/shared_invite/zt-1husbqm4x-BJ5La~XiEddk0r60QeDkog
Un contenido del que ya no se encuentra. Muchas gracias.
Muy bien explicado, te felicito rapido, al grano, buena logica y pedagogía.. sigue así recomendare tu canal
Que bueno que te sirvió.. Muchas gracias
Genio!!.. muchas gracias por compartir tu claro conocimiento.
perfecto muy explicado gracias hombre el unico video claro .
Excelente, muy útil y aplicable!
Muy buen video compañero!!! espero q te haya llegado Cafecito ☕! Saludos y espero que sigas con estos videos geniales !
La idea es esa, seguir subiendo videos, muchas gracias!
Muy bien explicado. Muchas gracias.
Excelente, muy bien explicado.
Buena explicacion, justo lo estaba necesitando para un nuevo proyecto. Si podes un video explicativo del Patrón Factory.
Buenisimo, voy a intentar aplicarlo. Yo estoy usando Laravel con Jetstream , imagino que seria lo mismo!
No use Jetstream aún, pero si deberías poder aplicar este patrón, ya que no es dependiente de un lenguaje o tecnología los patrones
wow que videos tan didacticos que tienes amigo
Muuuy bueno!
Muchas gracias
Muy bueno, gracias por compartir :)
Excelente!
Excelente vídeo, en la universidad nos hicieron utilizar este patrón pero no le ví mucha utilidad ya que era una aplicación pequeña y además ni lo explicaron bien.
Solo tengo una pregunta, había visto implementaciones de esto pero con una interface y la verdad no me quedaba muy claro el por qué, y veo que tú tampoco tuviste que hacer una, me podrías explicar por qué?
La interfaz lo que va hacer es definir los metodos que si o si tienen que llevar todos los repositorios que extiendan de esa interfaz entonces vas a tener el extend BaseRepo implement BaseInterface, eso depende ya de cada uno.
Lo que te recomiendo que veas es el video del patron decorador que esta en el canal que usa interfaz sobre el repositorio
@@return194 lo veré de inmediato, muchas gracias otra vez.
Bien explicado.
excelente profe, vengo desarrollando en laravel hace meses, tus videos me han servido bastante. El patron repositorio es genial por la abstraccion de la logica. Pero a veces siento que se pierde esa "magia de laravel" de desarrollar todo mas rapido, ejecutando estas consultas de eloquent en el servicio o clase que necesites. Es decir, necesitar hacer una consulta y tener que crearla en el repositorio y luego usarla, de la otra manera mas "rapida" seria hacer esas consultas con eloquent directamente en la clase. Que opinas al respecto?
Que eso que decis es para un proyecto muy chico, luego si no separas en responsabilidades se vuelve inmanejable y ahí es cuando te vas a demorar más tiempo en rehacer que empezar desde el principio haciendo lo correcto
@@return194 tienes razon
El controlador sigue accediendo a la Base de Datos, al utilizar el model binding
en que momento?
INCREIBLE... POR FAVOR UN CRUD CON ANGULAR O VUE!
Buenas, en un tiempo arrancaré a grabar un sistema api con react y laravel
Muchas gracias por tan maravillosas explicaciones... Lo mejor.
Ahora, tengo una duda.
¿Cual es la diferencia entre el patrón Adapter y Repository?
Para mi:
1. Ambos sirven como intermediarios, porque con el Adapter también se creo ese intermediario para evitar el acoplamiento.
Me alegro que te haya servido.
Ambos son intermediarios pero el repositorio es una capa intermedia entre tu logica y la base de datos abstrayendo lo que se usa para realizar las consultas a la BD, mientras que el adapter es una clase que hace de enlace entre dos clases que no son compatibles. Te dejo el link al video que tengo del patron adapter ruclips.net/video/DEriDJS9IR0/видео.html
Buenaso, pero como sabes cuando usar cual patron segun el tipo de aplicacion? por ejemplo para una aplicacion de agendamiento de citas medicas.
Excelente video, tengo una pregunta, como pasaría el UserRepository a través de Métodos genéricos? Es decir de un método que puede recibir tanto UserRepository, como PostRepository o algun otro repositorio ? teniendo en cuenta que cada repositorio implementa métodos específicos? GRACIAS
En que caso necesitarías hacer algo así?, en ese caso me imagino que tendrias un metodo que recibiría un parametro de tipo BaseRepository ya que todos extienden de este
Men una pregunta, si la idea es desacoplarse de Eloquent, por qué el método tiene que instanciar un modelo de Eloquent? por ejemplo en la creación, actualización y eliminación del usuario. Entiendo que se quiera reutilizar el método save() de cada modelo pero en teoría, toda esa lógica no tendría que estar en el UserRepository?
Para aclarar, me refiero a instanciar el modelo dentro del controlador para luego pasarlo como parámetro al UserRepository
Esta bien lo que decis y acá donde debe entrar otro patrón que es el factory (entre otros) que se encarga de crear las instancias para pasarlo al repository.
Ese video tengo pensado hacerlo más adelante
@@return194 Hola, muy buenos tus videos, de pronto ya tienes este vídeo hecho? Muchas gracias por compartir conocimiento.
@@monicaalejandravargas5485 Hola, A que te referís con este video hecho?
@@return194 al uso de Repository con Factory.... Gracias
Cual seria la diferencia entre un DAO y un repository?
En esencia son lo mismo, son abstracciones usadas para ocultar donde y como se ubican los datos. El DAO mas cerca de la base de datos mientras que el repositorio un poco mas arriba al mismo nivel que el dominio.
Esta bueno. Pero seguis acoplado a Eloquent y la DB.
Al recibir los modelos en los parametros?
Muy bueno, solo que tu clase debería llamarse UserRepository
La explicación esta buenisima!!, pero veo que todos los métodos de todas las clases son públicos. Esto no deberia ser asi, hay que encapsular logica con private, protected, haciendo uso de herencia. Todo no puede ser publico en una clase, ojo con ese tema. Igual para el ejemplo puntual, de repository, esta muy bien, ya que es solo un ejemplo.
muy buen video, pero vas demasiado rapido y no pude entender muy bien me perdi demasiado
Excelente 👌