What is the difference between DAO and Repository patterns

Question

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

User · Answer

In the spring framework  there is an annotation called the repository  and in the description of this annotation  there is useful information about the repository  which I think it is useful for this discussion      Indicates that an annotated class is a  Repository   originally   defined by Domain-Driven Design  Evans  2003  as  a mechanism for   encapsulating storage  retrieval  and search behavior which emulates a   collection of objects        Teams implementing traditional Java EE patterns such as  Data Access   Object  may also apply this stereotype to DAO classes  though care   should be taken to understand the distinction between Data Access   Object and DDD-style repositories before doing so  This annotation is   a general-purpose stereotype and individual teams may narrow their   semantics and use as appropriate       A class thus annotated is eligible for Spring DataAccessException   translation when used in conjunction with a   PersistenceExceptionTranslationPostProcessor  The annotated class is   also clarified as to its role in the overall application architecture   for the purpose of tooling  aspects  etc

User · Answer

Repository is more abstract domain oriented term that is part of Domain Driven Design  it is part of your domain design and a common language  DAO is a technical abstraction for data access technology  repository is concerns only with managing existing data and factories for creation of data   check these links   http   warren mayocchi com 2006 07 27 repository-or-dao  http   fabiomaulo blogspot com 2009 09 repository-or-dao-repository html

User · Answer

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

User · Answer

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  Additionally  as the aggregate root must handle the access of the other entities  then it may need to delegate this access to other DAOs

User · Answer

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  REPOSITORY  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   DAO - data access object  in other words - object used to access data  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 lt Permission gt  findPermissionsForUser String userId  User findUser String userId  Collection lt User gt  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  Finally 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

User · Answer

A DAO allows for a simpler way to get data from storage  hiding the ugly queries  Repository deals with data too and hides queries and all that but  a repository deals with business domain objects  A repository will use a DAO to get the data from the storage and uses that data to restore a business object  For example  A DAO can contain some methods like that -  public abstract class MangoDAO     abstract List lt Mango gt  gt  getAllMangoes       abstract Mango getMangoByID long mangoID      And a Repository can contain some method like that -    public abstract class MangoRepository         MangoDao mangoDao   new MangDao          Mango getExportQualityMango            for Mango mango mangoDao getAllMangoes               Here some business logics are being applied            if mango isSkinFresh   amp  amp mangoIsLarge               mango setDetails  quot It is an export quality mango quot                return mango                                 This tutorial helped me to get the main concept easily

User · Answer

Frankly  this looks like a semantic distinction  not a technical distinction  The phrase Data Access Object doesn t refer to a  database  at all  And  although you could design it to be database-centric  I think most people would consider doing so a design flaw   The purpose of the DAO is to hide the implementation details of the data access mechanism  How is the Repository pattern different  As far as I can tell  it isn t  Saying a Repository is different to a DAO because you re dealing with return a collection of objects can t be right  DAOs can also return collections of objects   Everything I ve read about the repository pattern seems rely on this distinction  bad DAO design vs good DAO design  aka repository design pattern

User · Answer

Repository are nothing but well-designed DAO    ORM are table centric but not DAO   There s no need to use several DAO in repository since DAO itself can do exactly the same with ORM repositories entities or any DAL provider  no matter where and how a car is persisted 1 table   2 tables  n tables  half a table  a web service  a table and a web service etc   Services uses several DAO repositories   My own DAO  let s say CarDao only deal with Car DTO I mean  only take Car DTO in input and only return car DTO or car DTO collections in output   So just like Repository  DAO actually is an IoC  for the business logic  allowing persitence interfaces not be be intimidated by persitence strategies or legacies  DAO both encapsulates the persistence strategy and does provide the domaine-related persitence interface   Repository is just an another word for those who had not understood what a well-defined DAO actualy was

User · Answer

in a very simple sentence  The significant difference being that Repositories represent collections  whilst DAOs are closer to the database  often being far more table-centric

User · Answer

DAO provides abstraction on database data files or any other persistence mechanism so that  persistence layer could be manipulated without knowing its implementation details   Whereas in Repository classes  multiple DAO classes can be used inside a single Repository method to get an operation done from  app perspective   So  instead of using multiple DAO at Domain layer  use repository to get it done  Repository is a layer which may contain some application logic like  If data is available in in-memory cache then fetch it from cache otherwise  fetch data from network and store it in in-memory cache for next time retrieval

User · Answer

Try to find out if DAO or the Repository pattern is most applicable to the following situation    Imagine you would like to provide a uniform data access API for a persistent mechanism to various types of data sources such as RDBMS  LDAP  OODB  XML repositories and flat files    Also refer to the following links as well  if interested   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

User · Answer

DAO and Repository pattern are ways of implementing Data Access Layer  DAL   So  let s start with DAL  first   Object-oriented applications that access a database  must have some logic to handle database access  In order to keep the code clean and modular  it is recommended that database access logic should be isolated into a separate module  In layered architecture  this module is DAL   So far  we haven t talked about any particular implementation  only a general principle that putting database access logic in a separate module   Now  how we can implement this principle  Well  one know way of implementing this  in particular with frameworks like Hibernate  is the DAO pattern    DAO pattern is a way of generating DAL  where typically  each domain entity has its own DAO  For example  User and UserDao  Appointment and AppointmentDao  etc  An example of DAO with Hibernate  http   gochev blogspot ca 2009 08 hibernate-generic-dao html   Then what is Repository pattern  Like DAO  Repository pattern is also a way achieving DAL  The main point in Repository pattern is that  from the client user perspective  it should look or behave as a collection  What is meant by behaving like a collection is not that it has to be instantiated like Collection collection   new SomeCollection    Instead  it means that it should support operations such as add  remove  contains  etc  This is the essence of Repository pattern    In practice  for example in the case of using Hibernate  Repository pattern is realized with DAO  That is an instance of DAL can be both at the same an instance of DAO pattern and Repository pattern    Repository pattern is not necessarily something that one builds on top of DAO  as some may suggest   If DAOs are designed with an interface that supports the above-mentioned operations  then it is an instance of Repository pattern  Think about it  If DAOs already provide a collection-like set of operations  then what is the need for an extra layer on top of it

[hibernate] What is the difference between DAO and Repository patterns?

Examples related to hibernate

Examples related to domain-driven-design

Examples related to ejb-3.0

Examples related to repository-pattern

Examples related to data-access-layer