If I understand DAOs correctly (and if I don't, please enlighten me) it seems most of the functionality usually implemented in a DAO is covered by the Hibernate API. By this I mean finders, loading, saving etc. If I decide that it is not important to me abstract the persistence mechanism to make it easy to swap out (after all Hibernate is so good, why would I ever want to change it out) is there a benefit to implementing DAOs? It seems to me that you end up putting a lot of stuff into the DAO that Hibernate is giving you for free. Being a person who likes free stuff I don't what to give it back without getting a good benefit. In reading the forums I believe that I have seen at leas some of the old time Hibernate developers mention that they routinely use DAOs when they build systems. This makes me think that I must be missing something obvious so I am hoping someone can help me understand.

I implement DAO to keep explicit Hibernate usage in one layer.
But session are opened earlier to benefit lazy loading etc...

Search the forum, you'll find good threads on that

Thanks for the response but I guess the thing I don't get is what does putting explicit Hibernate usage into a layer do for you other than making it easier to replace Hibernate with some other persistence layer. I thought the traditional reason to use DAO was to keep all the database access in one layer buy since the "Hibernate layer" already hides the database access isn't DAO then an unnecessary layer?

In our app, the DAOs have mostly ended up just being places to group finder-type methods together into logically consistent areas. That way they can be easily shared and are easy to find (makes the codebase that much clearer).

We have a common superclass for our DAOs, the DAO superclass and subclasses have been a convenient place to put lots of different hacks that we've had over time. That's kept them isolated from the rest of the code base and has made it much more likely that hacks will be removed because since they are isolated and centralised, they are easy to remove when we figure out what we really want to do.

Another thing we do with our DAOs is that they aren't just there for database persistence. We also do email, messaging and even some striaght RMI. All of these different comms channels (or at least, the outbound comms channels) are abstracted under the DAO concept (MailDAO.save(MailMessage) sending an email for example).

1. I can't use Hibernate everytime (LDAP access, CICS access etc...)
2. Keeping DB access (HQL for example) in one place help me to reuse for real the same code.

The Hibernate API is a generic API, while DAO interfaces are specific to your application. DAO interfaces clearly indicate what kind of domain objects can be loaded, and what parameters are available for finding them. A generic find method that can take any HQL string doesn't help here at all; this is particularly important in team development.

So I believe that DAOs do have significant value even on top of Hibernate, although in a special incarnation: DAOs designed for transparent persistence to not need fine-grained update calls because they can rely on changes getting persisted automatically within a transaction. You can't implement such DAO interfaces with plain JDBC then, of course, just with transparent persistence tools.

A further benefit is ease of testing. DAO interfaces are typically easy to mock; the Hibernate interfaces are much harder to mock. So if you want to test your business objects or controller in unit tests, decoupled DAOs are very convenient even with transparent persistence. Of course, you need to have flexible configuration to be able to replace your DAO implementations easily.

An important point is that DAOs should be flexible in terms of transaction participation: typically execute within their own if none exists, else silently participate in the existing one. This involves ThreadLocal Sessions and some generic means for transaction demarcation; a non-trivial effort, particularly if requiring more sophistication.

<plug>The Spring Framework provides such DAO and transaction support out-of-the-box, with first-class Hibernate integration. It also offers generic means for wiring any sort of application objects, to be able to switch to alternative implementations easily. See the article at http://www.hibernate.org/110.html for details.</plug>

Juergen

Good stuff. Thank you to all who replied

nice clarification.

has anyone looked at http://www.ociweb.com/jnb/jnbNov2003.html or implemented anything similar? (i may have to). can anyone share their experience?

thanks

For those of you using DAOs, how do you handle parent-children relationships? If you take advantage of Hibernate's features, it would seem to tie you code into Hibernate (although abstractly).

For example, I have a Parent object with a set of Child objects. When wanting to delete a parent object and the associated children object, a Hibernate-based DAO would allow calling ParentDAO.delete(parent) and have the children deleted automatically (if mapped correctly). But a different DAO may require looping through the children and calling ChildDAO.delete(child) for each and then calling ParentDAO.delete(parent).

So, how do others handle this? Does the ParentDAO have a reference to ChildDAO and automate this?


Cheers,
matthew

i am a newbie to hibernate and db's. i need to implement dao's in such a way that hibernate can be swapped out (boss says so). i have been reading the forums for a couple of weeks now. can you share the way you implement dao's?

i grok the dao pattern as defined by sun, but my implementation may require a couple of creational patterns instead of just the abstract factory.

the pojo's that are generated by hbm2java coupled with hibernate are *much* more than a dao. so it is not clear how to mix in the hibernate functionality into the data source, domain model, and service layers.

any pointers will be appreciated.

thanks

there nothing else to say....
we also have a DAO layer, you can search appfuse in google, if remember this demo uses a DAO layer, it could be a good start to understand how it works.

If you use the threadlocal Session + DAO pattern, hibernate will be totally transparent in your business & services layers.



Anthony

the demo does use HibernateDaoSupport from spirng. this is exactly the sort of thing i was looking for. i have seen posts on threadlocal Session + DAO pattern, but being a newbie, i am still focused on geting the first cut at an XXXDaoSupporrt interface as i need to be able to swap out hibernate easily and support different users uing the same service layer objects in the same servlet at the same time, but using different databases through the dao's. also found JdoDaoSupport at spring. comparing the implementations of these should be illuminating. also, the uml at http://opensource.objectsbydesign.com/spring/index.html is really helpful.

thanks for your prompt assistance.

Don't start with HibernateDaoSupport but rather with the "big picture" :-)

The very points of Spring's transaction and DAO support are to decouple transaction demarcation from DAOs (moving it to business facades), to allow for generic DAO interfaces (with generic DataAccessExceptions), and to allow for DAO implementations that can easily participate in any transaction strategy.

A further important point is that Spring's transaction support cares for the lifecycle of associated resources like Hibernate Sessions, transparently using ThreadLocals underneath. This is something that JTA / EJB CMT does not care about in the first place. Spring essentially removes the need for custom ThreadLocals that hold resources.

In terms of transaction management, Spring offers means for transaction demarcation at the business facade level (declarative or programmatic), keeping the actual transaction strategy (Hibernate, JTA, etc) a configuration choice. Neither the demarcating business objects nor the DAOs are tied to a specific strategy.

DAO implementations do not have to care about resource or transaction management but rather focus on the actual data access operations. Using Spring's HibernateTemplate, for example with the convenience base class HibernateDaoSupport, can result in one-liners for typical data access operations (see the Petclinic sample).

I hope that makes Spring's transaction and persistence support a bit clearer. Note that Matt Raible's AppFuse (mentioned by Anthony in an earlier post) is now built on a Spring-managed middle tier as of version 1.4, offering Spring's Hibernate and iBATIS SQL Maps support as data access strategies.

Juergen

I can't agree more. I recently converted an application to a spring managed middle tier. Previously the application consisted basically of struts actions calling dao methods, with transaction management in the dao:s. By introducing a service layer with spring managed declarative transactions, I was able to move to a "single database transaction per http request" model, compared to the previous version where a single http request could typically result in dozens of transactions. This is of course an important safety feature in case of writes, as the database is always in a consistent state from the viewpoint of the application when using the "single database transaction per http request" model. Although I haven't measured, there should also be improved performance as there is less need for database roundtrips because the applications isn't committing all the time.

The funny thing about spring is that it feels as if it doesn't get in the way (thanks to AOP and IOC I guess), while at the same time "nudging" you towards a "best practices" architecture. I guess it's a combination of good design, good documentation and good examples. Boing Boing! ;-)



While I haven't used appfuse to bootstrap my own projects, I have drawn a lot of inspiration from it. It very good code, IMHO, except for a few small grievances:

- He still seems to have his old checked DAOException class around, so lots of methods have to declare throws. The Hibernate DAO classes use DataAccessException from spring, but what does that help when the DAO interfaces still use DAOException? Anyway, this is quickly remedied.

- He has hashCode and equals() in his BaseObject (his base persistent class), made using the commons reflection builders. I prefer to specify these methods separately for every persistent class, specifying some static fields manually instead of using the reflection builders, because the reflection builders will obviously also use fields that will change during the lifetime of the object (there is an informative page on the hibernate wiki about making good equals and hashCode methods). Again, this is not a big problem to fix if one decides to use appfuse. But it is something to be aware of, as failing to do so can lead to subtle bugs appearing.