This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
No announcement yet.
Big DAO beans or a lot of small DAO beans?Page Title Module
I think it depends what makes more sense. How big does your DAO actually get? I think the biggest one we have is 600 ish lines, not really that bad. As long as it's dealing with one job it should be ok.
Last edited by karldmoore; Aug 27th, 2007, 04:08 PM.
"Each thing should do one thing and one thing well" and "anything should be implemented in one place and one place only" leads me to believe that one DAO per logical entity (*not* DB table ) is the way to go.
Hibernate entity class is a representation of a db table right???
It is perfectly feasible to map a single java Class to multiple tables, and vica versa in Hibernate. One DAO per class would seem to be a sensible strategy. One DAO per table would be breaking the contract of what DAOs are all about. It would essentially be an implementation leak of your schema.
It is dangerous to talk about specifics too much because obviously every situation is different.
However, in general, if I have an Order class (regardless of how many tables there were) then yes, I would have an OrderDAO. If I have a Person (which is extended by Employer and Employee) then I would probably have a PersonDAO.
I wouldn't necessarily say the same thing about the service layer (or Business Objects). Creating a PersonService and OrderService may be the right thing to do, but then again it might not be needed.
It is worth taking a step back here: the BO/Service is responsible for implementing use cases, and therefore the methods should be use case orientated. The DAOs/Repositories OTOH are responsible for persisting/retrieving entities.
So yes, one DAO per entity hierarchy (i.e. PersonDAO *not* PersonDAO, EmployeeDAO) but maybe not one Service per entity.