One big Service class or several small classes?
I asked this question on the Spring Forums a couple of days ago, but I didn't get a response, so I'll try it here.
Looking through the Spring's petclinic and jpestore applications - both seem to advocate one single class to interface with the database (hibernate or dao/ibatis). I also noticed this pattern in Java Open Source Programming. Is this a recommended pattern or do you still think there's value in several service-level classes (i.e. one for each DAO)? I imagine the single interface and impl could grow quite large on a big project. In fact, in the Spring examples, the Manager isn't even a Business Delegate, it's really a Persistence Manager.
BTW, the Petclinic app is a helluva plug for Hibernate. The Hibernate implementation class is 53 lines, and the JDBC implementation class is 770 lines! If you're still using JDBC over Hibernate, please explain why you put yourself through the pain?
I do like the simplicity of the Single Manager approach, but I tend to do 1 Manager for each DAO (or something resembling this pattern). What do you advocate? AppFuse follows the 1-Manager to 1-DAO pattern. Should I switch to the Single Manager pattern?