hibernate - patron - repository pattern
¿Cuál es la diferencia entre los patrones DAO y Repository? (8)
DAO es una abstracción de la persistencia de datos. El repositorio es una abstracción de una colección de objetos.
DAO se consideraría más cerca de la base de datos, a menudo centrada en la tabla. El repositorio se consideraría más cercano al dominio, y se ocuparía solo de las raíces agregadas. Se podría implementar un repositorio utilizando DAO, pero no haría lo contrario.
Además, un repositorio es generalmente una interfaz más estrecha. Debería ser simplemente una colección de objetos, con 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 a las entidades generalmente se rastrean por UnitOfWork por separado.
Parece común ver implementaciones llamadas Repository que en realidad son más de un DAO, y por lo tanto, creo que hay cierta confusión sobre la diferencia entre ellas.
¿Cuál es la diferencia entre los objetos de acceso a datos (DAO) y los patrones del repositorio? Estoy desarrollando una aplicación utilizando Enterprise Java Beans (EJB3), Hibernate ORM como infraestructura y Diseño impulsado por dominio (DDD) y Desarrollo dirigido por prueba (TDD) como técnicas de diseño.
DAO y el patrón de repositorio 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 que la lógica de acceso a la base de datos se aísle en un módulo separado. En arquitectura en capas, este módulo es DAL.
Hasta ahora, no hemos hablado de ninguna implementación en particular: solo un principio general que coloca la lógica de acceso a la base de datos en un módulo separado.
Ahora, ¿cómo podemos implementar este principio? Bueno, una forma conocida de implementar esto, en particular con marcos como Hibernate, es el patrón DAO.
El patrón DAO es una forma de generar DAL, donde normalmente, cada entidad de dominio tiene su propio DAO. Por ejemplo, User y UserDao , Appointment y 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 repositorio? Al igual que DAO, el patrón de Repository es también una forma de lograr DAL. El punto principal en el patrón de Repository 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 ser instanciada como Collection collection = new SomeCollection() . En su lugar, significa que debe admitir operaciones como agregar, eliminar, contiene, etc. Esta es la esencia del patrón del Repositorio.
En la práctica, por ejemplo, en el caso de utilizar Hibernate, el patrón de Repository se realiza con DAO. Esa es una instancia de DAL que puede ser al mismo tiempo una instancia de patrón DAO y patrón Repository.
El patrón de repositorio no es necesariamente algo que se construye sobre 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 de Repositorio. Piénselo, si los DAO ya proporcionan un conjunto de operaciones similares a una colección, ¿cuál es la necesidad de una capa adicional sobre ella?
El repositorio no es más que un DAO bien diseñado.
Los ORM son centrados en la tabla pero no DAO.
No hay necesidad de usar varios DAO en el repositorio, ya que el mismo DAO puede hacer exactamente lo mismo con los repositorios / entidades ORM o cualquier proveedor DAL, sin importar dónde y cómo se guarde 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 repositorios / DAO.
Mi propio DAO, digamos que CarDao solo trata con el DTO del coche, quiero decir, solo toma el DTO del coche como entrada y solo devuelve las colecciones del DTO del coche o DTO del coche en la salida.
Entonces, al igual que Repository, DAO en realidad es un IoC, para la lógica de negocios, lo que permite que las interfaces de persitencia no se dejen intimidar por las estrategias o legados de persitencia. DAO encapsula la estrategia de persistencia y proporciona la interfaz de persistencia relacionada con el dominio. Repositorio es solo una palabra más para aquellos que no habían entendido lo que realmente era una DAO bien definida.
Francamente, esto parece una distinción semántica, no una distinción técnica. La frase Objeto de acceso a datos no se refiere a una "base de datos" en absoluto. Y, aunque podría diseñarlo para que esté centrado en la base de datos, creo que la mayoría de las personas consideraría hacerlo por una falla de diseño.
El propósito de la DAO es ocultar los detalles de implementación del mecanismo de acceso a datos. ¿En qué se diferencia el patrón del repositorio? Por lo que puedo decir, no lo es. Decir que un repositorio es diferente a un DAO porque está tratando / devolviendo 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 repositorio parece depender de esta distinción: mal diseño de DAO versus buen diseño de DAO (también conocido como patrón de diseño de repositorio).
La diferencia clave es que un repositorio 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 repositorio delegue la persistencia real de las raíces agregadas a un DAO. Además, como la raíz agregada debe manejar el acceso de las otras entidades, es posible que deba delegar este acceso a otros DAO.
Ok, creo que puedo explicar mejor lo que he puesto en los comentarios :). Básicamente, puede ver ambos como iguales, aunque DAO es un patrón más flexible que el Repositorio. Si desea usar ambos, usaría el Repositorio en sus DAO-s. Te explico cada uno de ellos a continuación:
REPOSITORIO:
Es un repositorio de un tipo específico de objetos: le permite buscar un tipo específico de objetos, así como almacenarlos. Por lo general, SOLO manejará un tipo de objetos. Por ejemplo, AppleRepository le permitiría hacer AppleRepository.findAll(criteria) o AppleRepository.save(juicyApple) . Tenga en cuenta que el repositorio está utilizando los términos del modelo de dominio (no los términos de la base de datos, nada relacionado con cómo se conservan los datos en cualquier lugar).
Es muy probable que un repositorio almacene todos los datos en la misma tabla, mientras que el patrón no requiere eso. Sin embargo, el hecho de que solo maneje un tipo de datos hace que esté conectado lógicamente a una tabla principal (si se usa para la persistencia de la base de datos).
DAO: objeto de acceso a datos (en otras palabras, objeto utilizado para acceder a datos)
Un DAO es una clase que localiza los datos para usted (es principalmente un buscador, pero se usa comúnmente para almacenar también los datos). El patrón no le limita a almacenar datos del mismo tipo, por lo que puede tener fácilmente un DAO que localice / almacene objetos relacionados.
Por ejemplo, puede tener fácilmente UserDao que expone métodos como
Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)
Todos estos están relacionados con el usuario (y la seguridad) y se pueden especificar bajo 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 ellos y se expresan más cerca del modelo de dominio y casi no contienen ninguna referencia de DB), pero la forma en que se usan puede ser ligeramente diferente, siendo DAO un poco más flexible / genérico, mientras que Repository es un poco más específico y restringido a un solo tipo.
Repository es un término más abstracto y orientado al dominio que forma parte de Domain Driven Design, es parte de su diseño de dominio y es un lenguaje común. DAO es una abstracción técnica para la tecnología de acceso a datos. 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
Trate de averiguar si DAO o el patrón de Repositorio es más aplicable a la siguiente situación: Imagine que le gustaría proporcionar una API de acceso a datos uniforme para un mecanismo persistente para varios tipos de fuentes de datos como RDBMS, LDAP, OODB, repositorios 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