Repository vs DAO

I am coming to the end of one project and am the prelim stages of another and am trying to get a nice easy to understand architecture that can be clearly explained to new comers. I have come into one issue that I have never really worried about before, however curiosity has got the better of me. It’s the issue of Repositories vs DOA’s.

From my reading around the most logical version that A) makes sense and b) highlight why people don’t really worry about the difference is shown below:

Valid
CustomerRepository : ICustomerRepository //This just passes calls straight through to the DAO

CustomerDAO : ICustomerRepository, ICustomerDAO

OR (more appropriate and most common)
CustomerDAO : ICustomerRepository, ICustomerDAO

Not Valid
CustomerRepository : ICustomerRepository, ICustomerDAO //This concrete class should not exist, shift the ICustomerRepository to the CustomerDAO

CustomerDAO : ICustomerDAO

Often a repository tier will not be used in an application stack as there is no added benefit in the extra level of indirection. However when the IFooRepository start to allow the “creeping in” of the underlying persistence framework then its time to refactor the IFooRepository and separate it out to a separate concrete class and allow the IFooDao deal with the specific persistence issues.

The repository methods should be very generic and as Fabio Kung puts it:

• Repositories are domain objects, daos aren’t.

So when would repositories be there own concrete class? When IFooRepository != IFooDao. Separate out the repository from the DAO, its just that it rarely happens and if it does probably has not warranted the effort to separate.

For more see:
http://fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/