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
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