> > That's one of the reasons I wrote the Ars Machina Generic DAO, Generic > DAO-Hibernate and Generic Controller: all the common methods (findAll, > findById, save, update, delete, findByExample, etc) are already written. I > don't have to rewrite them for every entity class.
My generic dao is pretty much the same and includes everything you said. The design began when I started using T4 and really just added Generics to what was already available with Spring's HibernateTemplate. I've extended to include findByQuery and a few others that I find REALLY handy during development to take advantage of Tapestry class reloading. (I later add methods to the relevant DAO to replace it, and get *QL out of the view.). > > > To really muck it up, I've got DAO's that extend a generic base DAO. > > That's fine until the class hierarchy gets a few levels deep and now I'm > > writing > > DAO's for Person, Customer, and Employee. > > That's what I want to provide default service implementations in > Tapestry-IoC: not having to implement trivial DAOs and controller > implementations, just the ones that have methods that my generic DAO and > generic controller don't have, and still use the whole "user inteface > classes never use DAOs directly" mantra. Well that makes sense. It's the repetitive stuff that makes me feel like there's a better way. Jonathan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
