¿Cuál es la diferencia entre los patrones DAO y Repository?

¿Cuál es la diferencia entre los objetos de acceso a datos (DAO) y los patrones de repository? Estoy desarrollando una aplicación que utiliza Enterprise Java Beans (EJB3), Hibernate ORM como infraestructura y Domain-Driven Design (DDD) y Test-Driven Development (TDD) como técnicas de diseño.

DAO es una abstracción de la persistencia de datos. El repository es una abstracción de una colección de objetos.

DAO se consideraría más cercano a la base de datos, a menudo centrado en la tabla. El repository se consideraría más cercano al Dominio, y solo se trataría en Raíces agregadas. Un repository podría implementarse utilizando DAO, pero no haría lo contrario.

Además, un Repositorio es generalmente una interfaz más estrecha. Debe ser simplemente una colección de objetos, con un Get(id) , Find(ISpecification) , Add(Entity) . Un método como Update es apropiado en un DAO, pero no en un Repositorio: cuando se usa un Repositorio, los cambios en las entidades normalmente serían rastreados por UnitOfWork por separado.

Parece común ver implementaciones llamadas Repository que son realmente más de un DAO, y por lo tanto, creo que hay cierta confusión sobre la diferencia entre ellos.

OK, creo que puedo explicar mejor lo que he puesto en los comentarios :). Entonces, básicamente, puede ver ambos como iguales, aunque DAO es un patrón más flexible que el Repositorio. Si desea usar ambos, debería usar el Repositorio en sus DAO-s. Explicaré cada uno de ellos a continuación:

REPOSITORIO:

Es un repository de un tipo específico de objetos: le permite buscar un tipo específico de objetos y almacenarlos. Por lo general, SÓLO manejará un tipo de objetos. Por ejemplo, AppleRepository le permitirá hacer AppleRepository.findAll(criteria) o AppleRepository.save(juicyApple) . Tenga en cuenta que el Repositorio utiliza términos del Modelo de dominio (no términos de DB, nada relacionado con la forma en que los datos se conservan en ninguna parte).

Un repository probablemente almacenará todos los datos en la misma tabla, mientras que el patrón no lo requiere. Sin embargo, el hecho de que solo maneja un tipo de datos lo hace lógicamente conectado a una tabla principal (si se usa para la persistencia de DB).

DAO – objeto de acceso a datos (en otras palabras, objeto utilizado para acceder a los datos)

Un DAO es una clase que localiza datos para usted (en su mayoría es un buscador, pero comúnmente se usa para almacenar los datos). El patrón no le restringe a almacenar datos del mismo tipo, por lo que puede tener fácilmente un DAO que localiza / almacena objetos relacionados.

Por ejemplo, puede tener fácilmente UserDao que expone métodos como

 Collection findPermissionsForUser(String userId) User findUser(String userId) Collection findUsersForPermission(Permission permission) 

Todos aquellos están relacionados con el usuario (y la seguridad) y se pueden especificar en el mismo DAO. Este no es el caso para el Repositorio.

Finalmente

Tenga en cuenta que ambos patrones realmente significan lo mismo (almacenan datos y abstraen el acceso a él y se expresan más cerca del modelo de dominio y apenas contienen referencia DB), pero la forma en que se utilizan puede ser ligeramente diferente, DAO siendo un poco más flexible / genérico, mientras que el Repositorio es un poco más específico y restrictivo para un tipo solo.

El patrón DAO y repository son formas de implementar Data Access Layer (DAL). Entonces, comencemos con DAL, primero.

Las aplicaciones orientadas a objetos que acceden a una base de datos deben tener cierta lógica para manejar el acceso a la base de datos. Para mantener el código limpio y modular, se recomienda aislar la lógica de acceso a la base de datos en un módulo separado. En architecture en capas, este módulo es DAL.

Hasta ahora, no hemos hablado de una implementación en particular: solo un principio general que pone la lógica de acceso a la base de datos en un módulo separado.

Ahora, ¿cómo podemos implementar este principio? Bueno, uno sabe cómo implementar esto, en particular con marcos como Hibernate, es el patrón DAO.

El patrón DAO es una forma de generar DAL, donde típicamente, cada entidad de dominio tiene su propio DAO. Por ejemplo, User y UserDao , Appointment and AppointmentDao , etc. Un ejemplo de DAO con Hibernate: http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html .

Entonces, ¿qué es el patrón de repository? Al igual que DAO, el patrón Repositorio es también una forma de lograr DAL. El punto principal en el patrón Repositorio es que, desde la perspectiva del cliente / usuario, debe verse o comportarse como una colección. Lo que se entiende por comportarse como una colección no es que tenga que Collection collection = new SomeCollection() una instancia como Collection collection = new SomeCollection() . En cambio, significa que debe admitir operaciones como agregar, eliminar, contener, etc. Esta es la esencia del patrón Repositorio.

En la práctica, por ejemplo, en el caso de usar Hibernate, el patrón Repository se realiza con DAO. Esa es una instancia de DAL que puede ser a la vez una instancia del patrón DAO y del patrón Repositorio.

El patrón de repository no es necesariamente algo que se construye encima de DAO (como algunos pueden sugerir). Si los DAO están diseñados con una interfaz que admite las operaciones mencionadas anteriormente, entonces es una instancia del patrón Repositorio. Piénselo, si los DAO ya ofrecen un conjunto de operaciones similares a las de una colección, entonces ¿para qué sirve una capa adicional?

Francamente, esto parece una distinción semántica, no una distinción técnica. La frase Objeto de acceso a datos no se refiere en absoluto a una “base de datos”. Y, aunque podría diseñarlo para que esté centrado en la base de datos, creo que la mayoría de la gente consideraría hacerlo como un defecto de diseño.

El objective de la DAO es ocultar los detalles de implementación del mecanismo de acceso a datos. ¿Cómo es el patrón del Repositorio diferente? Por lo que puedo decir, no lo es. Decir que un repository es diferente a un DAO porque está tratando con / devolver una colección de objetos no puede ser correcto; Los DAO también pueden devolver colecciones de objetos.

Todo lo que he leído sobre el patrón de repository parece depender de esta distinción: diseño DAO malo frente a buen diseño DAO (también conocido como patrón de diseño de repository).

Repositorio es un término más abstracto orientado al dominio que forma parte del Diseño Dirigido por Dominio, es parte del diseño de su dominio y un lenguaje común, DAO es una abstracción técnica para la tecnología de acceso a datos, el repository solo se ocupa de la gestión de datos y fábricas existentes para la creación de datos.

revisa estos enlaces:

http://warren.mayocchi.com/2006/07/27/repository-or-dao/ http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html

La diferencia clave es que un repository maneja el acceso a las raíces agregadas en un agregado, mientras que DAO maneja el acceso a las entidades. Por lo tanto, es común que un repository delegue la persistencia real de las raíces agregadas en un DAO. Además, como la raíz agregada debe manejar el acceso de las otras entidades, puede necesitar delegar este acceso a otros DAO.

El repository no es más que DAO bien diseñado.

ORM son table centric pero no DAO.

No es necesario utilizar varios DAO en el repository ya que DAO mismo puede hacer exactamente lo mismo con repositorys / entidades ORM o cualquier proveedor DAL, sin importar dónde y cómo persiste un automóvil 1 tabla, 2 tablas, n tablas, media tabla, una servicio web, una tabla y un servicio web, etc. Los servicios utilizan varios DAO / repositorys.

Mi propio DAO, digamos que CarDao solo trata con Car DTO, es decir, solo toma Car DTO en entrada y solo devuelve colecciones de DTO o auto DTO de auto en salida.

Así que al igual que Repository, DAO en realidad es un IoC, para la lógica empresarial, lo que permite que las interfaces persitence no se dejen intimidar por las estrategias de persistencia o los legados. DAO encapsula la estrategia de persistencia y proporciona la interfaz de persistencia relacionada con el dominio. El repository es solo otra palabra para aquellos que no habían entendido lo que realmente era un DAO bien definido.

Intente averiguar si DAO o el patrón Repository es más aplicable a la siguiente situación: imagine que desea proporcionar una API uniforme de acceso a datos para un mecanismo persistente a varios tipos de fonts de datos, como RDBMS, LDAP, OODB, repositorys XML y archivos planos.

También consulte los siguientes enlaces, si está interesado:

http://www.codeinsanity.com/2008/08/repository-pattern.html

http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/

http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx

http://en.wikipedia.org/wiki/Domain-driven_design

http://msdn.microsoft.com/en-us/magazine/dd419654.aspx

Intereting Posts