hibernate 3: Christian Bauer's notes

[mmiranda]

Hi, im very new to the spring framework, im trying to understand the hole thing.
Im very interested on the "first class" support for hibernate, reading around i found very good tutorials on the topic, but suddently i found this,

http://hibernate.bluemars.net/110.html


do you have any comments on the bold notes from Christian Bauer?
Should i be worried about the spring-hibernate future support and integration ?
thanks

[katentim]

Should i be worried about the spring-hibernate future support and integration ?

I don't think so. The Spring team are top developers. I guess it's a small concern that the tone of the notes are unsupportive of Spring, but that doesn't really stop Spring from integrating.

[steven.warren]

The hibernate guys have a container philosophy to sell (JBOSS), and in general seem to think the world revolves around them. So don't be suprised that they say a container and specifically JBOSS and Hibernate is the only answer for everything for all time...

[katentim]

I guess there's also a concern that Spring makes it easy to switch from Hibernate to Toplink, JDO, iBatis, JDBC, OJB. Not something Hibernate would want to promote.

I think you'd find migration from Hibernate2 to Hibernate3 simpler if you were using Spring than just Hibernate2 - that says something about good design to me.

I'll try to add some specific replies here:

Spring's generic transaction management for DAOs is of particular interest

Note: It's also a proprietary alternative.

But...it's fully portable - from application to container A to container Z.
And don't forget that you can mix JDBC and Hibernate in the same transaction (being careful of you cache of course)

While some of this template functionality had its use for Hibernate 2.x, it is no longer needed for Hibernate 3.x...I assume rollback-on-exception is wanted here

...and the consistent exception hierarchy

This kind of refactoring is hard to do if the native API (Session) is being hidden from you and flattened into something not envisioned by the original designers.

You can always obtain the Session in the HibernateCallback. That's not "hard to do".

Note: Without Spring dependencies, the code above can be reduced to:

Similar to Christian's comment "If you put a little extra effort into HibernateUtil...", with a little bit of effort you can add you own convenience methods to reduce the example to a one liner, if you find you need it.

To summarize: Spring transaction demarcation has some benefits if you don't know your deployment environment

I don't get this. It's more powerful in rules declaration, and useful for testing outside of the container..

and don't want to maintain a few lines of code yourself in the HibernateUtil class (or simply don't want to copy it from the Hibernate documentation and/or CaveatEmptor)

The less cut 'n' paste, and the more code managed by a tested quality framework the better.

[katentim]

There is a related thread on the user mailing list.

[lukasbradley]

The original page has been removed from the Hibernate site. Here is an archived link.

http://web.archive.org/web/200411300...e.org/110.html