Announcement Announcement Module
Collapse
No announcement yet.
Repository vs DAO Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Repository vs DAO

    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

  • #2
    A good explanation of the repository pattern by Martin Fowler :

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

    Comment


    • #3
      Originally posted by georgea View Post
      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

      Comment


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

        Comment


        • #5
          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

          Comment


          • #6
            Originally posted by georgea View Post
            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

            Comment


            • #7
              Thanks Debasish - that's what I was looking for

              Comment


              • #8
                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

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      Originally posted by aks View Post
                      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.
                      Well, the object at hand should not know, but that does not mean that the domain model as such is agnostic. If it is part of the usecase to prevent duplicates on user creation (which usually is the case), then that fact has to be represented in the domain model (usually in some repository class).

                      So you should not just pass in an object in a generic method that invokes makePersistent() but use a dedicates service method that inserts a new user and performs the necessary checks to prevent duplicates.

                      I would guess that ROO does support this, but I do not know the details (yet).

                      Regards,
                      Andreas

                      Comment


                      • #12
                        Originally posted by Andreas Senft View Post
                        So you should not just pass in an object in a generic method that invokes makePersistent() but use a dedicates service method that inserts a new user and performs the necessary checks to prevent duplicates.
                        I think this is what Eric Evans calls Domain Service in his DDD book. The domain service can in turn talk to repositories.

                        Cheers.
                        - Debasish

                        Comment


                        • #13
                          Originally posted by debasishg View Post
                          I think this is what Eric Evans calls Domain Service in his DDD book. The domain service can in turn talk to repositories.
                          Yep. That was the background of my suggestion. And that is why I suspect that it should be achievable with ROO.

                          Comment

                          Working...
                          X