I did a hybrid of both your approaches: first a parent class, the generic DAO, which knows about generally connecting to the db etc., and then subclassed it for a number of specific DAO's, that override and/or extend to know about specific business object stuff.

But with the value objects that you pass between your business objects and your DAO's, you do get into the usual object-relation impedance mismatch problem, when you have some single "objects" that sometimes (but not always) need multiple rows from db relations, and you have to work out which value objects can be single valued, or which have to be Map or List types, and when to fetch minimally vs. greedy/extensively, i.e. when anything is accessed in a business object leading to a value object/DAO that can either bring back single valued info OR dig in to all the multiple rows of sub-objects (from member fields etc.).

So in a situation like this you might get into designing a cacheing strategy (in accessing a Customer address, do you also go and fetch all info up front, about all their Accounts, Orders, etc.? possibly returning loads of data that you don't all need yet? Or fetch none of it up front, leave it all for later if needed, possibly leading to lots more db roundtrips later? Or fetch just some it now, and the rest later, guessing what might be most needed, or what might be most expeditious to fetch in advance and avoid roundtrips, rather than wait for later?). Unless you go ahead and use CMP EJB's to do this for you (we've just been doing our own, so far, with DAO's, no EJB's yet).