muchas gracias por compartir tu conocimiento, podrías hacer algún vídeo explicando una clase Repository con propiedades genéricas?, es decir el GetAll(), etc, muchas gracias.
no iba a hacer algo así, pero es buena idea asi que seguramente si que haga algo así, eso sí, seguramente sea al final del curso, así que habra 4 o 5 vídeos antes que ese, pero en principio si haré algo. Un saludo!
@@NetMentor sería genial, porque creo que un repositorio genérico con algunos métodos nos podría ahorrar unos cuantos métodos que se repiten, muchas gracias de antemano, siempre te sigo.
Hola buen video! Yo en su momento lo intente aplicar de esta forma, pero usaba dapper como ORM/Mapeador pero cuando se tenian ya como 10-20 entidades, se me hacia muy complicado la gestion de las interfaces y/o interfaces especificas para cada caso o consulta individual, al final termine optando por una interfaz generica con las operaciones insert/update/select y una clase abstracta donde basicamente a punta de reflection construyo sql generico y al vuelo AL final se encapsula en una clase contenedora y puedo hacer metodos para consultas complejas
Aunque ya es opinión de cada uno, pero para mi EF Core es la abstracción que yo llegaría a necesitar si es que ocurre ese lejano suceso de cambiar de base de datos, ya que EF Core tiene muchos providers (de los populares y relacionales) en el cual, aunque no fuera tan automático, puedo cambiar la base de datos sin problema. Para el testing ocurre lo mismo, si es unit testing y no importa la BD, podemos usar una base de datos en memoria, para integration tests, podríamos usar SQL Local DB. Repository pattern y unit of work para mi suele ser mucha ceremonia, y para mi punto de vista, poco beneficio. Tal vez me gusta hacer las cosas "sucias" jaja Soy fan tuyo, gracias por todos tus vids y contenido!! 👍🏻👍🏻
cuando implementes el Unit Work haslo con un ejemplo una transacion guardando en dos tablas que creo que ese es el objetivo del Unit Work todo o nada, gracias por tus videos.
Hola felicitacione por tu video, muy bueno. Puedes por favor decirme o si tienes ejemplos mucho mejor, cuando usar el Patron Repository y cuando usar el Mediator? Agradezco tu orientacion.
Hola, hablando de repositorios. ¿Cómo organizarías los repositorios si tienes por un lado Clientes y por otro lado requieres consultar las ventas de un cliente o el estado de cuentas del mismo? ¿Harías un repositorio a parte del repositorio de clientes para obtener las ventas y estados de cuentas o las ventas y estados de cuenta serían métodos del repositorio del cliente?
entiendo que en un monolito, si es un monolito personalmente preferiría multiples repositorios. Aunque va a ser mucho menos trabajo tenerlo solo un repositorio por base de datos.
@@NetMentor muchas gracias por tu respuesta. No sé a que te refieres con el termino "monolito" pero entendí la idea. Lo que sí es verdad que obteniendo ese tipo de información te sales del CRUD de Clientes, para generar el estado de cuentas tienes que examinar las ventas al clientes y los pagos que el mismo ha realizado. Quizás vaga la pena un repositorio aparte, pese que a nivel de clases posiblemente la clase cliente tenga un método Cliente.EstadoDeCuentas(...)
Este pregunta me parese interesante y yo tengo algunas dudas, como se implementa repository tiene el problema que el caso de uso tiene dependencias sobre todos lo que expone la interface repositorio, creo que si se usa specification desaparece este problema, otra solucion podriser depender de una interface de repository espesifica para el caso de uso, es decir que solo exponga los miembos que usara el caso de uso y no todos los que se usan para todos los casos de uso. por lo tanto cada caso de uso tendria que exponer una interface para repository espesifica. lo ultimo me parese lo mas rasonable.
Uso este patrón en mi compañía, sin embargo no soy tan fan. Se pierde mucho el poder de EF ya que no siempre basta con los métodos Add, Update, Remove, Get... sí, al final terminas haciendo otros métodos que básicamente hacen lo mismo que ya hacen los de EF...
Estoy totalmente de acuerdo a mi me sobra la capa del patrón repository perdemos la versatilidad del dbcontext. He visto servicios a los que se inyectan 20 repositorios complicando la lógica mucho. La implementación de ese mismo servicio se simplifica usando directamente el dbcontext. Luego ese servicio se inyecta en los controladores. El uso de dbcontext no creo que sea usar directamente la base de datos que abstrae. El dbcontext se puede hacer independiente de la base de datos relacional y hacer tests. Luego esta el horror de hacer entidades muy diferentes en muchas capas y mapeos que se realizan sin conocer como funciona en tracking de los estados de las entidades que llegan al contexto de entity framework
Te tengo en alta estima como ejemplo a seguir. Me gustaría que expusieras un ejemplo de organización cuando en una solución se tienen que utilizar varias bases de datos, con múltiples modelos distintos, viewmodels, etc. Me gustaría ver un vídeo de cómo organizar las dll's de los proyectos muy grandes. Es mejor tener un único proyecto con todos los modelos o distintos proyectos con modelos por contexto de negocio. Cómo aconsejas realizar las llamadas desde un servicio, Service1, que tiene inyectada la capa de repositorio, IRepository1, y necesita obtener datos del repositorio, IRepository2. ¿Recomiendas inyectar el servicio que tiene inyectado IRepository2 o mejor inyectar la capa IRepository2 en Service1? Estoy en la fase de reorganizar un proyecto enorme con deoendencias circulares, mal uso de IoC, definición de clases anidadas, paso de Interfaces e implementaciones en el constructor, etc.
es un poco dificil de saber sin ver el código, pero si el servicio simplemente hace un crud simple, sin lógica de negocio, puedes insertar el repositotrio, aunque no sería lo ideal (ya que siempre hay algo de lógica de negocio) Luego en un monolito muy grande, lo que yo recomiendo primero es convertirlo a un monolito modular, donde los boundaries están bien identificados y no se traspasan y de ahí intentar mejorar, pero ese es el primer paso siempre, porque si no, veo imposible un refactor. un saludo
Yo estoy un poco confundido. Estoy trabajando con Dapper y Stored Procedures. Para mi me alcanza para el crud el repository, pero ¿Qué pasa el método buscar, por dar un ejemplo? ¿Ese lo pongo en el repository? ¿O lo tengo que trasladar a otra capa? Yo me encontré con que los Stored Procedures me resuelven bastantes cuestiones de lógica. Agradecería mucho una devolución jaja. ¡Mil gracias por tus videos y saludos desde Argentina!
si tienes la lógica en Store procedures al final la capa de datos es simplemetne un proxy a la bbdd, no vas a tener ni tablas ni nada en el repository. simplemente pon detrás de los metodos del repository la llamada al SP en vez de a las tablas y ya.
En principio no, me explico. Si los usuairos tienen productos al nivel carro de la compra(en plan 5 o 10 productos) es complicarse de más, cuando simplemente puedes devlover toda la información haciendo el include. En cambio si un usuario es una tienda dentro de Amazon, donde puedes tener miles de productos si ya que son dos entidades muy grandes, en mi opinión claro.
muchas gracias por compartir tu conocimiento, podrías hacer algún vídeo explicando una clase Repository con propiedades genéricas?, es decir el GetAll(), etc, muchas gracias.
Blog: www.netmentor.es/entrada/repository-pattern
Twitter: twitter.com/NetMentorTW
muchas gracias por compartir tu conocimiento, podrías hacer algún vídeo explicando una clase Repository con propiedades genéricas?, es decir el GetAll(), etc, muchas gracias.
no iba a hacer algo así, pero es buena idea asi que seguramente si que haga algo así, eso sí, seguramente sea al final del curso, así que habra 4 o 5 vídeos antes que ese, pero en principio si haré algo.
Un saludo!
@@NetMentor sería genial, porque creo que un repositorio genérico con algunos métodos nos podría ahorrar unos cuantos métodos que se repiten, muchas gracias de antemano, siempre te sigo.
Hola buen video!
Yo en su momento lo intente aplicar de esta forma, pero usaba dapper como ORM/Mapeador pero cuando se tenian ya como 10-20 entidades, se me hacia muy complicado la gestion de las interfaces y/o interfaces especificas para cada caso o consulta individual, al final termine optando por una interfaz generica con las operaciones insert/update/select y una clase abstracta donde basicamente a punta de reflection construyo sql generico y al vuelo
AL final se encapsula en una clase contenedora y puedo hacer metodos para consultas complejas
Aunque ya es opinión de cada uno, pero para mi EF Core es la abstracción que yo llegaría a necesitar si es que ocurre ese lejano suceso de cambiar de base de datos, ya que EF Core tiene muchos providers (de los populares y relacionales) en el cual, aunque no fuera tan automático, puedo cambiar la base de datos sin problema.
Para el testing ocurre lo mismo, si es unit testing y no importa la BD, podemos usar una base de datos en memoria, para integration tests, podríamos usar SQL Local DB.
Repository pattern y unit of work para mi suele ser mucha ceremonia, y para mi punto de vista, poco beneficio. Tal vez me gusta hacer las cosas "sucias" jaja
Soy fan tuyo, gracias por todos tus vids y contenido!! 👍🏻👍🏻
Concuerdo totalmente.
idem!
cuando implementes el Unit Work haslo con un ejemplo una transacion guardando en dos tablas que creo que ese es el objetivo del Unit Work todo o nada, gracias por tus videos.
En el siguiente vídeo el martes lo tendrás así 😉
Capo total
shhh que buena explicacion
Hola felicitacione por tu video, muy bueno.
Puedes por favor decirme o si tienes ejemplos mucho mejor, cuando usar el Patron Repository y cuando usar el Mediator?
Agradezco tu orientacion.
son dos patrones diferentes, no es uno o el otro. utiliza mediator cuando lo necesites y repository pattern pues lo mismo.
Hola, hablando de repositorios. ¿Cómo organizarías los repositorios si tienes por un lado Clientes y por otro lado requieres consultar las ventas de un cliente o el estado de cuentas del mismo? ¿Harías un repositorio a parte del repositorio de clientes para obtener las ventas y estados de cuentas o las ventas y estados de cuenta serían métodos del repositorio del cliente?
entiendo que en un monolito, si es un monolito personalmente preferiría multiples repositorios. Aunque va a ser mucho menos trabajo tenerlo solo un repositorio por base de datos.
@@NetMentor muchas gracias por tu respuesta. No sé a que te refieres con el termino "monolito" pero entendí la idea. Lo que sí es verdad que obteniendo ese tipo de información te sales del CRUD de Clientes, para generar el estado de cuentas tienes que examinar las ventas al clientes y los pagos que el mismo ha realizado. Quizás vaga la pena un repositorio aparte, pese que a nivel de clases posiblemente la clase cliente tenga un método Cliente.EstadoDeCuentas(...)
Que opinas de implementar un solo metodo Get que devuelve un IQuearyable en el repositorio en lugar de tener varios de esos metodos?
Opino que es buena idea en muchos casos y grabaré un vídeo está semana sobre eso, el post del blog ya lo tengo creado haha
Este pregunta me parese interesante y yo tengo algunas dudas, como se implementa repository tiene el problema que el caso de uso tiene dependencias sobre todos lo que expone la interface repositorio, creo que si se usa specification desaparece este problema, otra solucion podriser depender de una interface de repository espesifica para el caso de uso, es decir que solo exponga los miembos que usara el caso de uso y no todos los que se usan para todos los casos de uso. por lo tanto cada caso de uso tendria que exponer una interface para repository espesifica. lo ultimo me parese lo mas rasonable.
Uso este patrón en mi compañía, sin embargo no soy tan fan. Se pierde mucho el poder de EF ya que no siempre basta con los métodos Add, Update, Remove, Get... sí, al final terminas haciendo otros métodos que básicamente hacen lo mismo que ya hacen los de EF...
Estoy totalmente de acuerdo a mi me sobra la capa del patrón repository perdemos la versatilidad del dbcontext. He visto servicios a los que se inyectan 20 repositorios complicando la lógica mucho. La implementación de ese mismo servicio se simplifica usando directamente el dbcontext. Luego ese servicio se inyecta en los controladores. El uso de dbcontext no creo que sea usar directamente la base de datos que abstrae. El dbcontext se puede hacer independiente de la base de datos relacional y hacer tests. Luego esta el horror de hacer entidades muy diferentes en muchas capas y mapeos que se realizan sin conocer como funciona en tracking de los estados de las entidades que llegan al contexto de entity framework
Te tengo en alta estima como ejemplo a seguir. Me gustaría que expusieras un ejemplo de organización cuando en una solución se tienen que utilizar varias bases de datos, con múltiples modelos distintos, viewmodels, etc.
Me gustaría ver un vídeo de cómo organizar las dll's de los proyectos muy grandes. Es mejor tener un único proyecto con todos los modelos o distintos proyectos con modelos por contexto de negocio.
Cómo aconsejas realizar las llamadas desde un servicio, Service1, que tiene inyectada la capa de repositorio, IRepository1, y necesita obtener datos del repositorio, IRepository2.
¿Recomiendas inyectar el servicio que tiene inyectado IRepository2 o mejor inyectar la capa IRepository2 en Service1?
Estoy en la fase de reorganizar un proyecto enorme con deoendencias circulares, mal uso de IoC, definición de clases anidadas, paso de Interfaces e implementaciones en el constructor, etc.
Muchas gracias por tu conocimiento, esfuerzo y trabajo. Espero algún día estar a tu nivel.
Un saludo enorme
es un poco dificil de saber sin ver el código, pero si el servicio simplemente hace un crud simple, sin lógica de negocio, puedes insertar el repositotrio, aunque no sería lo ideal (ya que siempre hay algo de lógica de negocio)
Luego en un monolito muy grande, lo que yo recomiendo primero es convertirlo a un monolito modular, donde los boundaries están bien identificados y no se traspasan y de ahí intentar mejorar, pero ese es el primer paso siempre, porque si no, veo imposible un refactor.
un saludo
Yo estoy un poco confundido. Estoy trabajando con Dapper y Stored Procedures. Para mi me alcanza para el crud el repository, pero ¿Qué pasa el método buscar, por dar un ejemplo? ¿Ese lo pongo en el repository? ¿O lo tengo que trasladar a otra capa? Yo me encontré con que los Stored Procedures me resuelven bastantes cuestiones de lógica. Agradecería mucho una devolución jaja. ¡Mil gracias por tus videos y saludos desde Argentina!
si tienes la lógica en Store procedures al final la capa de datos es simplemetne un proxy a la bbdd, no vas a tener ni tablas ni nada en el repository.
simplemente pon detrás de los metodos del repository la llamada al SP en vez de a las tablas y ya.
hola! una duda, en vez de hacer un repositorio por cada entidad no sería mejor hacer uno generico que trabaje con tipos genericos?
El curso no está terminado 😉 creo que en dos o tres semanas pondré ese vídeo (el post ya está en la web si lo quieres ir a ver )
Si tuviera un api que muestra información de usuarios y sus productos, se debe crear un repository para usuarios y otro para productos?
En principio no, me explico. Si los usuairos tienen productos al nivel carro de la compra(en plan 5 o 10 productos) es complicarse de más, cuando simplemente puedes devlover toda la información haciendo el include.
En cambio si un usuario es una tienda dentro de Amazon, donde puedes tener miles de productos si ya que son dos entidades muy grandes, en mi opinión claro.
Este patrón es lo que se llama Unit of Work?
nope, ese lo veremos en el siguiente vídeo, aunque se podría decir que estan relacionados, bueno en la mayoría de códigos "van a ir juntos"
Cómo se llama tu IDE?
jetbrains rider
muchas gracias por compartir tu conocimiento, podrías hacer algún vídeo explicando una clase Repository con propiedades genéricas?, es decir el GetAll(), etc, muchas gracias.