Thanks. OK, I will put interfaces in services.dao and do implementations in services.dao.hibernateImpl.
In the past (version 1) of the application, I put the transaction logic in the pages. But then I have multiple pages potentially using the same logic, hence the need to separate the core DAO from page, maintain in one place. I am also intrigued by the "generic DAO" concept in the tawus blog, but fail to see how to implement, so far. Would be great if this concept, if I am understanding correctly, could be standardized to pick up directly from the entities directory for basic CRUD. And similarly pick up from, say, the services.dao.* package, sub-directory for custom queries on the same entities. Then, Tapestry could offer a CRUD application out-of-the-box just by specifying the entities. May be the "problem" is, indeed, trying to shoehorn the DAO into Tapestry as a service. RESTful API can be (should be) application independent, loosely coupled with the application. Trade off being you lose the ability to inject, use activation context etc. -- View this message in context: http://tapestry.1045711.n5.nabble.com/DAO-Pattern-tp5714718p5714723.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
