Repository vs DAO: Patrones de diseño para acceder a bases de datos
HTML-код
- Опубликовано: 19 июл 2023
- Tanto el patrón de diseño de software DAO como el Repository son 2 patrones muy famosos y utilizados. Uno más del mundo clásico Java y otro del ecosistema DDD. En el vídeo de hoy vemos sus diferencias y decidimos cuál nos convence más.
﹤🍍﹥ CodelyTV
├ 🎥 Suscríbete: ruclips.net/user/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🧔🏻 Twitter Javi: / javiercane
├ 💂♀️ Twitter Rafa: / rafaoe
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🥋 Academy: codely.com/academy
└ 📕 Catálogo cursos: bit.ly/cursos-codely 
Наука
En 1:30 con Typescript se podría usar Partial en lugar del map y para no volver a definir todos los parámetros como opcionales. Yendo un poco más allá se podría usar algo como Partial para omitir las propiedades que no se puedan actualizar de un usuario.
La explicación más clara que he visto al respecto. Gracias
Muy claro. Buen video!
Chicos, una pregunta. Tienen en mente preparar algo sobre DDD con Python a la brevedad? A mí por lo menos me sería de gran ayuda. Desde ya muchas gracias. Muy buenos cursos!
Muchas gracias. Video excelente, Reconozco que incluso viendo el vídeo me costó al principio entender la diferencia entre DAO y Repository hasta que habéis puesto el ejemplo de que con DAO, si tienes 4 tablas para hacer insert de un usuario tendrías 4 DAOs mientras que con Repository solo tendrías. En ese momento he visto la luz, hehehe.
Si basicamente el DAO es una capa a mas bajo nivel de abstracción para los datasources.
Una duda con respecto al repository: ¿no se estaría encapsulando lógica de negocio en él, cuándo sólo debería tener lógica de acceso a datos? Entiendo que todas las operaciones en base de datos vinculadas a la creación del usuario conformarían una regla de negocio.
Tengo entendido que el patron DAO solo se centra en UN objeto o UNA entidad, mietras que el patron Repository, se centra en COLECCIONES de Objetos (Por ende muchas tablas relacionadas entre si, osea muchas entidades relacionadas por herencia), si alguien me puede corregir en caso de estar equivocado se lo agradeceria..
Muy bien video, yo soy mucho de usar Repository Pattern, una duda, que editar es el que muestran que se ve muy clean
Es que el DAO puedes usarlo como complemento del Repository para precisamente abstraer el acceso a datos -DATA ACCESS OBJECT: DAO-. Tienes un repository de users y tienes el dao que funciona como la interfaz media entre el repository y por ejemplo postgresql. Y ahi es donde se pone interesante porque puedes tener un DAO que implemente el acceso a users en otro tipo de base de datos.
Me acabáis de reventar la cabeza. Llevo haciendo "repositorios" un tiempo y ahora me entero que estoy haciendo más DAOS Que otra cosa. Vaya tela... Unos ejemplitos "reales" con múltiples tablas referenciando al mismo objeto (user con datos básicos, direcciones, favoritos, suscripciones... Cada uno representado en una tabla de persistencia) comparando repository con dao estaría bien. Gracias!
Es que el DAO puedes usarlo como complemento del Repository para precisamente abstraer el acceso a datos -DATA ACCESS OBJECT: DAO-. Tienes un repository de users y tienes el dao que funciona como la interfaz media entre el repository y por ejemplo postgresql. Y ahi es donde se pone interesante porque puedes tener un DAO que implemente el acceso a users en otro tipo de base de datos.
Si realizamos una consulta por ejemplo un JOIN de dos entendidas donde estaraia ese metodo ? en un repository nuevo?
El uso de repositorios está más que nada relacionado con DDD y en ese contexto lo ideal es tener repositorios solamente para los agregados y además (sin dejar de considerar el performance) es recomendable cargar siempre el agregado completo en memoria, es decir que tu método FindById, Search (o cualquiera que sea el que te devuelva un único agregado) te lo debería devolver con todas las entidades y value objects relacionados ya cargados. Podría llegar a parecer extremo, pero hay que recordar que en DDD el agregado es el encargado de mantener la consistencia de su propia información y por lo tanto siempre debe de tener acceso a ella estando en memoria.
Entonces, pensar en hacer un JOIN con otra entidad sería más una cuestión de un DAO que de un repositorio, pues en ese contexto los datos son los que dictan la estructura y no el dominio en sí.
@04:57 no comprendo cuando dices que ese instante el vídeo que tendrían 4 inserts en DAO pero en Respository sería solo uno, pero si ese repository tira de una entity que tiene relacion con 3 entities más al final si que habría 4 inserts o se me ha ido la cabeza
Básicamente para el repository un User es una entidad de dominio y para los DAOs es un objeto de datos. El repository podría usar varios DAOs porque de repente en ese caso habrían 4 fuentes de datos donde actualizar el usuario y que ojo, no necesariamente tienen que ser las 4 fuentes de datos guardando los mismos datos, podrías tener una fuente que guarda datos personales, otra que guarda la seguridad, otra que hace algun calculo sobre algún objeto de dominio relacionado al usuario y así sucesivamente.
¿Que lenguaje o framework es lo que muestran como ejemplo.?
El lenguaje es Typescript
Disculpen, yo tengo una duda. En vez de DAO no sería mejor utilizar Active Record? Soy nuevo en esto de los patrones de diseño.
Tengo la misma consulta!, por ejemplo en frameworks tan populares como Ruby On Rails, Pheonix (Elixir) o Django (Python) como se ve el uso del Active Record?
En el caso de diseños orientados a dominios el patrón active récord es una mala práctica ya que estas amarrando lógica de persistencia con el negocio o sea las entidades lo que lleva a un acoplamiento entre el core del negocio con la persistencia de un framework o librería
Con Active Record lo que sucede es que incluye tanto logica de negocio como logica de acceso a datos y por tanto se carga la abstraccion y acopla. En cambio un DAO deberia ser especificamente disenado como el acceso a una fuente de datos y nada mas.
Active Record es un mecanismo de persistencia, como lo es un ORM. DAO es un patrón de diseño cuya implementación puede usar cualquier mecanismo. Incluso SQL pelado
Para mi siguen siendo lo mismo hay una linea muy delgada para diferenciarlos y creo que esto en vez de ayudar a la industria genera mas confusiones; de hecho en el libro de DDD de vaughn vernon tampoco dan una explicación clara que te permita diferenciarlos; repositorio es un rename de dao.
yo lo veo como que antes se usan los dao para diferencialo como una capa para acceso a datos. Mientras que repository luego surgio y quienes usabamos siempre dao, no sabiamos donde que va a esto de los repository.Sin embargo repository son lo interfaces y por ende el acoplamiento es menor. Si cumples los principios solid te dice que tu clase jamas debe depender de una implementacion exacta. Por tanto usar repository te esta dando es ventaja. Como tambien que ya tienen un monton de implentaciones debajo del capo y en cambio con DAO estaba mas pensando para que cuando hagas la conexion a DB siempre lo veias para un base de datos especifica. Queries nativas. Luego surgio hibernate para lidiar el tema de que solo te centras es un solo lenguaje para abstraerte de cada sintaxis de cada base de datos. Incluso cuando usas repository debajo creo que usa hibernate, porque en los logs sale de eso. entonces yo usaria siempre repository por esa abstracción y mejoras a la hora de cumplir los principios solid. Pero siempre queda la duda seguimos usando el patron DAO para diferencia esa capa? o directamente pongo repository que seria lo mismo? ya que es tan basico lo que hacemos es que no nos hacen falta agregar otra capa mas DAO y luego por debajo que use repository. Se puede hacer pero es mas codigo al pepe. SAlvo que el proyecto lo amerite y sea un monolito o algo asi, pero hoy todo es orientado a microservicios, y liarse tanto con eso es una perdida de tiempo.
En pocas palabras repository es una agrupacion de daos en las que el repository es quien gobierna sobre los daos y los agrupa?
Si, en esencia. Puedes tener un repository que use un DAO de users, otro de roles y otro de permissions por ejemplo y el Repository usaria los 3 para realizar operaciones sobre ellos y ya.
ajaj no me puedo sacar de l acabeza todavia primero ahcer los DAO y estaticos.. Mañas del 2000
😢😢😢😢😢
No, un DAO no tiene porqué tener una sola tabla.