Spring hibernate template when to use and why?

Question

Greetings, Currently developing small web service application where response from web service (using CXF + Spring) processed and saved to database. To work with database I am using Hibernate(3.5). Browsing some Hibernate + Spring example on web, I often can see the usage of HibernateTemplate so I am a bit confused about this moment and wanted to ask:

Do you use HibernateTemplate in your Hibernate3 applications? When does HibernateTemplate can make your development life better and based on what points can I decide do I need to use it or not ?

Thanks.

Answer 1

All spring templates (hibernate, jdbc, rest, jpa etc.) have the same pros and cons:

Pro: They perform common setup routines for you, let you skip the boilerplate and concentrate on the logic you want.

Con: you are coupling your application tightly to the spring framework. For this reason, Spring recommends that HibernateTemplate no longer be used.

Specifically, what HibernateTemplate did for you was to automatically open and close sessions and commit or rollback transactions after your code executed. However, all of this can be achieved in an aspect-oriented way using Spring's Declarative Transaction Management.

Reference:

• Spring Reference: ORM: Hibernate for the current suggested Spring Hibernate usage patterns
• Spring Reference: Classic Spring Usage: HibernateTemplate

---

Update:

As of Spring 3.1 (and newer versions), HibernateTemplate has been removed. See Hibernate for the currently suggested usage patterns.

Answer 2

Let me clarify one thing that Spring's HibernateTemplate will not be supported going forward, that means Hibernate 4+ versions do not support HibernateTemplate. So it is advised to use declarative transaction management as suggested by Sean.

Answer 3

HibernateTemplate encapsulates a number of things for you to make your life easier.

It's your choice to use it or not. For that matter, you can work with a database without Hibernate. Spring's JDBC stuff is very good. You might find it easier to get your problem done without having to learn Hibernate.

Answer 4

The OpenSessionInViewFilter pattern is effective. This opens a Hibernate session & binds it to your thread, during the processing of every request. OpenSessionInView also extends the Session and loadability to View rendering & the View layer, which decreases coupling & complexity (by enabling that to 'just work').

My philosophies don't really agree with aspect-based/ declarative transaction management. I like to make major state-change/ lifecycle events 'explicit', since they should be absolutely definite -- not weakly dependent on multiple hidden & indirect layers, which may or may not work.

It provides a point to debug at.

TX commit is only one line of code; but it's the major one you want to breakpoint on. No longer syntactically, than a 'transactional' declaration; but a hell of a lot more definite.

Frankly I find "user commands" or "requests", which are the proper place to initiate a transaction & control transactionality from, should be well-structured, well-identified & fairly explicit within the application.

(I did have trouble getting the aspect class-loading stuff to work, trying it when it first came out. My assessment is that compared to well-written OO code, aspect has only limited marginal value.)

Tip: I generally make a helper class, to make it really convenient to get the Session & to commit the Transaction.

HbHelper or somesuch.