Repository vs DAO

[georgea]

Hi all,

I have seen the usage of the Repository pattern in place of the DAO pattern. To me they both look the same. Can anyone please suggest advantages for using the repository pattern instead of the DAO?

Thanks,
George

[julien.dubois]

A good explanation of the repository pattern by Martin Fowler :

http://www.martinfowler.com/eaaCatalog/repository.html

[debasishg]

Can anyone please suggest advantages for using the repository pattern instead of the DAO?

A Repository is a domain level artifact and mostly corresponds to an Aggregate Root. One repository can be implemented in terms of multiple DAOs. One DAO roughly corresponds to a single table. Hence you can say that a Repository is at a higher level of abstraction than the DAO.

HTH,
- Debasish

[georgea]

Thanks for your replies. Are there any code examples to look at - as I am still not sure how this pattern is implented.

[Andreas Senft]

I have no code examples at hand. But from its structure a repository is similar to a DAO, except that it corresponds to an aggregate root (as already has been said by Debasish). In the simple case, the repository could itself contain the database operations. For more complex cases it would itself delegate to DAO instances.

I suggest to have a look at the "Domain Driven Design" book by Eric Evans and "POJOs in Action" by Chris Richardson. The first one explains the intentions and fundamentals while the second one has a more practical approach.

Hope that helps,
Andreas

[debasishg]

Thanks for your replies. Are there any code examples to look at - as I am still not sure how this pattern is implented.

Some time back I had blogged on a related topic. Though it does not have complete implementation, some example snippets are there for you to browse .. if this is of any help.

Cheers.
- Debasish

[georgea]

Thanks Debasish - that's what I was looking for

[Alan Stewart]

You might want to check out Ben Alex's framework and code generation system called ROO. ROO is a DDD enabler.

You code domain objects and ROO generates the DTOs, facades (service layer artefacts) and it uses a shared Repository. I've used it successfully in two projects at Woolworths.

ROO saved us a lot of time in development.
Cheers
Alan

[Andreas Senft]

I'm also eager to put my hands on ROO (saw Ben's presentation at SpringOne). But as far as I know it has not been published yet.

[Alan Stewart]

Yes, ROO has been taken on by I21 and will (hopefully) be open-sourced later this year.

I have issues with my rich domain model designs that ROO may or may not help me.

Consider this scenario: a client wishes to create a new User - in ROO, one constructs a User DTO object in the web tier for example, and presents it to a ROO Facade method called createUser(UserDto). ROO will instantiate a User domain object by reflectively calling a User constructor that has some arguments such as the user name. (Domain objects in ROO are rich domain objects and only provide a private no-arg constructor for Hibernate and the assembler implementation, being Dozer - dozer.sourceforge.net.) The ROO facade will the call the assembler to copy non-state managed properties and then call a Repository method, makePersistent(DomainObject) to persist the new User object (to Hibernate in our case). Great! All I code is the DO and ROO has done the rest.

What about when there exists a user with the same user name you have provided? Domain Objects should no nothing about how they are persisted, so you ideally you don't inject the Repository to check to see if a user already exists.
What is the best way of doing this? Currently, in the web tier I first call a facade method that does this check and if the user already exists, I can trap a business exception and prevent the new user from being created. but I believe this is a bit of a hack, as I have now coded some business logic in the web tier. I could have coded the same logic in the facade (service layer), but this is doing the same thing.

I strongly believe in a rich domain model, that the service layer should be thin and all the business logic is to exist in the domain objects, but I don't know how this can happen fully, regardless of using ROO or not.

Any insight would be much appreciated.
Cheers
Alan