0

For quick prototyping I have been actively using Hibernate. Recently I came back to an old project and I wondered why I had a lot of DAOs with what I suspect is commonly named feature bloat. E.g.

I have a DAOs for single entities that contains from 15 to 20 methods each.

Recently I have been using Hibernate Generic D.A.O. Framework but I still think that the same problem arises when I'm trying to create custom data access logic and my code Olfaction starts to detect bad smells.

Is there a guideline for this scenarios?

3
  • Sounds like either a case of YAGNI, or you just need to factor out your business logic. Can your DAO not just contain simple CRUD operations with some filtering allowed?
    – BrandonV
    Commented Feb 21, 2014 at 20:20
  • Well, recently I have been using Spring Data JPA repositories to avoid the boilerplate of creating my own search methods yet I think that maybe you're right about factor out the business logic.
    – ElderMael
    Commented Feb 21, 2014 at 22:11
  • Visit the similar questions: "Service layer vs DAO — Why both?", "How essential is it to make a service layer?" for more understanding where you can search link on other sources about it. Also recommend you example of project which have the DAO and Service layers. Commented Feb 22, 2014 at 10:05

1 Answer 1

1

What you are talking about looks more like specific Repository pattern, than generic DAO.

And while many people will tell you there is some gain from using repositories as way to abstract the data access, there are some people that disagree. No only is repository's abstraction YAGNI bordering on wishful thinking, you get the problems of having 1000+1 methods that look like "GetCustomerBy(arbitrary number of fields)With(arbitraryNumberOfFields)" making it even harder to maintain. This becomes even more obvious when you start using ORMs like Hibernate.

I recommend reading Repository is the new Singleton and The evils of the repository abstraction layer by Ayende.

1
  • Omg I just red a few articles and got convinced to use Repositories are good to keep complex logic inside them that I don't want to have in my DAO objects and not in my Client-Service objects.. So now I am not getting it. How and where would I maintain Aggretage Roots? Commented Jul 7, 2015 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.