The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

OrNot (1) [Avatar] Offline
#1
hi, there,
This is a real great book. I like it very much.
Recently, I am studing the Pojo in action as well as Hibernate in action. I notice that the common and different points in the design about the layered architecutre.
In Hibernate in action , the Chapter 8 gives a sample that uses DAO in the facade but in the POJO in action, a repository is used instead of DAO pattern.
In my understanding, two books manage to use the DDD to keep the application layer thiner , that is, push most of the biz logic into the domain model . However
, the POJO in action goes further by introducing the repositroy and put all the database , espeically the collection operations, into it and eventually the service layer ( facace?) is really thin.
My question is , if it is right about my understanding and if right, we can use the DAO pattern in the repository , right? Will it suffer from the over-refactoring problem?


Thanks in advance

OrNot
ceracm (110) [Avatar] Offline
#2
Re: About the thin bizLogic
Hi

I am glad that you like the book.

The DAO versus Repository issue is discussed periodically on the Domain-Driven Design mailing list: http://groups.yahoo.com/group/domaindrivendesign/

Generally, conceptually DAOs and Repositories are different but in practice the code looks similar.i.e. they both call persistence framework APIs. I've not found it that useful in practice to have the repository call a DAO. The repository would almost always consist of one-line methods that invoke the DAO.

Having said that, I once wrote a repository that contained logic that was not persistence framework specific. It was filtering the results returned by Hibernate. If you have a lot that kind of logic in your repository you might be able to improve you design by moving the persistence framework specific code into a separate DAO.

I hope this helps.

Chris