Hi All,

I'm using hibernate and have started writing my DAO classes. Is it allowed / a good idea to have a DAO class do some calculations and other lookups in order to generate the top level data needed by the caller, or should Hibernate DAOs just be wrappers around basic CRUD functionality only?

TY

Typically, calculations should go in a service layer. So, client does its stuff, calls a service layer, and the service layer calls the DAOs. So, my first desire is to use a service layer.

For a good tutorial on using DAOs with Hibernate, check out this tutorial:

http://www.hiberbook.com/HiberBookWeb/l ... vanceddaos

Hi,

The business logic (some calculations and other lookups in order to generate the top level data) should be handled at the business service layer.
DAOs should be wrappers around CRUD functionalities.

Regards,
Sudhir

RE the examples shown in the
http://www.hiberbook.com/HiberBookWeb/l ... vanceddaos
link, what's the reason that the DAO class contains begin and commit transaction methods?
Shouldn't the starting, rollback and finishing of transactions be a detail implemented within the DAO itself?

TY,
Fred

Simplicity is the only reason those methods are there, and even then, I would prefer them to be outside of the DAO.

No, no, no! You don't want transaction handling inside of the DAO! TOTAL ANTI-PATTERN!

The layer invoking the DAO should be starting and committing the transactions - NEVER inside of the DAO. You may want to hit three tables and do it all inside of one transaction. If each DAO starts and commits its own transactions, you can't call three different DAOs and have them run as a single unit of work. So, the transaction stuff should be outside of the DAOs.

Again, the DAO example there is later used in a simple JSF application. A service layer begins and commits transactions, and the DAO simply had little methods to expose the basic transaction methods. Even then, I dislike the DAO being the source of the transaction; a different abstraction would be even better.

-Cameron McKenzie