Data Access Object

Overview;

The Data Access Object serves the purpose of translating a native language object to a data store. Essentially, Object Relationship Mapping. This is also closely tied in with the Repository pattern.

This pattern is largely implemented by hibernate. Thus we use a very thin CRUD and Query layer. Transactions at this point are not utilized, because of the atomic or read-only nature of these operations. DAO operations should inherit transactions from the Service Object, which may incompass many calls to the DAO layer.




Why not the Active Record Pattern?

Much can be said about the Active Record Pattern.

Pros

• Very easy to persist an object into storage. 
• Many frameworks which utilize the active record pattern (ie Grails or Rails) auto-generate the code for you.
• Conceptually it is easy. 

Cons (what I see as cons)

• I don't like mixing business and pojo. I want my models to hold properties and small purposeful methods. I don't want data storage to be on an object or related to an object. It feels confined. (It doesn't have to be, but...)
• I don't like having hundreds of 'find*' queries on an object. It just doesn't feel right. 
• I like to do stuff with persistent objects before I save or delete them. Now, we can run a wrapper around .save and .delete, but I find it easier to run a cross cut against the dao object. And I don't necessarily want to crosscut a pojo and make it a proxy. It seems like that might break things. Now, most active records have hooks, but I just prefer to have it in a dao.