What is the difference between Data Access Objects (DAO) and Repository patterns? I am developing an application using Enterprise Java Beans (EJB3), Hibernate ORM as infrastructure, and Domain-Driven Design (DDD) and Test-Driven Development (TDD) as design techniques.
The key difference is that a repository handles the access to the aggregate roots in a an aggregate, while DAO handles the access to entities. Therefore, it's common that a repository delegates the actual persistence of the aggregate roots to a DAO.
DAL is an architectural term, DAOs are a design detail.
The difference between DAO and service is that a DAO is an organization without a central manager. The definition of a DAO is a company that operates without any human involvement. The difference between the two is that a DAO does not have labor while a service has human labor.
The Repository pattern. Repositories are classes or components that encapsulate the logic required to access data sources. They centralize common data access functionality, providing better maintainability and decoupling the infrastructure or technology used to access databases from the domain model layer.
DAO
is an abstraction of data persistence.Repository
is an abstraction of a collection of objects.
DAO
would be considered closer to the database, often table-centric.Repository
would be considered closer to the Domain, dealing only in Aggregate Roots.
Repository
could be implemented using DAO
's, but you wouldn't do the opposite.
Also, a Repository
is generally a narrower interface. It should be simply a collection of objects, with a Get(id)
, Find(ISpecification)
, Add(Entity)
.
A method like Update
is appropriate on a DAO
, but not a Repository
- when using a Repository
, changes to entities would usually be tracked by separate UnitOfWork.
It does seem common to see implementations called a Repository
that is really more of a DAO
, and hence I think there is some confusion about the difference between them.
OK, think I can explain better what I've put in comments :). So, basically, you can see both those as the same, though DAO is a more flexible pattern than Repository. If you want to use both, you would use the Repository in your DAO-s. I'll explain each of them below:
It's a repository of a specific type of objects - it allows you to search for a specific type of objects as well as store them. Usually it will ONLY handle one type of objects. E.g. AppleRepository
would allow you to do AppleRepository.findAll(criteria)
or AppleRepository.save(juicyApple)
. Note that the Repository is using Domain Model terms (not DB terms - nothing related to how data is persisted anywhere).
A repository will most likely store all data in the same table, whereas the pattern doesn't require that. The fact that it only handles one type of data though, makes it logically connected to one main table (if used for DB persistence).
A DAO is a class that locates data for you (it is mostly a finder, but it's commonly used to also store the data). The pattern doesn't restrict you to store data of the same type, thus you can easily have a DAO that locates/stores related objects.
E.g. you can easily have UserDao that exposes methods like
Collection<Permission> findPermissionsForUser(String userId) User findUser(String userId) Collection<User> findUsersForPermission(Permission permission)
All those are related to User (and security) and can be specified under then same DAO. This is not the case for Repository.
Note that both patterns really mean the same (they store data and they abstract the access to it and they are both expressed closer to the domain model and hardly contain any DB reference), but the way they are used can be slightly different, DAO being a bit more flexible/generic, while Repository is a bit more specific and restrictive to a type only.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With