Are you saying 1 entity = 1 concrete, non-generic dao? Which basically means if we wanted to use generics, we should still extend the generic class for each concrete entity. (Similar to the HiA GenericEjb3Bean pattern.) I didn't think of using one interface per DAO type, however... that helps keep the # of files down.
1 entity = 1 interface. This is good, as you can now have several implementations, mix or switch between them. Maintenance is easier if everything uses interfaces. Extending the generic for the implementation(s) is correct, the problem is that you need a separate class, can't do it inline. Btw, if you have looked at the CaveatEmptor DAO stuff, the EJB3 persistence isn't finished at all. Only the dao.hibernate.* package is good.
So if I wanted to implement a conversation using EJB3 DAOs, the DAO code would essentially have to be aware that it will be used in a conversation? (IOW, DAO will need to know in advance if it needs to be @Stateful and with an extended @PersistenceContext.) This essentially gives the DAO higher awareness of business logic. My concept of a DAO is that it is a dumb object that is only aware of the underlying DB schema. In fact, I've been trying to code for SEAM in a manner such that I can essentially package all the Entities/DAOs in one jar (or .par) and it can be used by any number of .ear/.war packages, and maybe someday by POJOs. Maybe I'm misunderstanding something...
You have the choice how you'd like to layer your app. You can as well make one of your controller beans @Stateful and keep the extended persistencecontext there.
