So should you still use Spring's HibernateTemplate and/or JpaTemplate??

中国人最喜欢访问的网站
只要注册ofo就送你10块钱，还等什么，快来注册吧

I was reading an article by Vigil Bose on TSS the other day and saw the usage of the HibernateDaoSupport class. Since this is no longer a recommended way of using Hibernate from Spring, I thought I might as well just blog about it another time.

不建议使用HibernateDaoSupport。

With the advent(n. 到来；出现；) of Spring 2.0, it has become possible to start using the Hibernate Session API directly again. The question is whether or not it is wise to abandon the use of the HibernateTemplate when working with Hibernate, or any other template-based approaches Spring features.

Using Spring XxxTemplates

In Spring 1.0, we introduced a revolutionary way of working with data access APIs that threw checked exceptions. The template approach Spring features along with its transaction synchronization manager and the extensive(adj. 广泛的；大量的；广阔的) use of runtime exceptions makes any TCFTC (short for try/catch-finally-try/catch as we coined(杜撰) it back in 2005) often found in data access code entirely obsolete. Below you can see (a simplified version and not entirely precise version of) what Spring’s template approach does for you (with specific code snippets that you would otherwise have to write).

Acquisition of connection: If transaction synchronization is active (which it is, if you’re using Spring’s transaction management infrastructure), most of the times any of the Spring templates are using the same connection across the entire thread (things are actually a bit more complicated than that, but that would lead us too much into the gory details).

Participation in a transaction Again, when using transaction management features, Spring will automatically associated any new connection with the current transaction. This again, all depends on the current propagations settings and so on, but whichever way you look at it, your core code is not affected by it.

Specification of the SQL: This is what you (obviously) have to do yourself. The SQL ideally uses bind parameters, to avoid any chances of SQL injection from happening. Parameters are passed to the JDBC template as arguments.

Creation / execution of statement and iterating over result set: After you’ve specified the SQL, Spring is going to create the statement for you, set any parameters you may have specified, execute it and loop over the result set for you.

Parse result from result set: You can opt for parsing the result set yourself if you like (or if you have complex parsing requirements), or you can have Spring result a list of primitives, or just one value from the result set.

Handling and translation of exceptions: This is where Spring translates any exceptions that might have occurred to Spring’s own DataAccessException hierarchy, automatically insulating calling code from the data access technology in use.

Releasing of connection: This is the last piece of the puzzle where Spring releases any resources used. Of course, if transaction synchronization is active, the resources might not be released immediately.

Templates are available for several APIs such as:

JDBC (JdbcTemplate)
Hibernate (HibernateTemplate)
iBatis (SqlMapClientTemplate)
JDO (JdoTemplate)
TopLink (TopLinkTemplate)
Messaging (JmsTempate)
Transaction management (TransactionTemplate)
JNDI (JndiTemplate)

Are templates really necessary?

The templates add a lot of value when using an API that uses checked exceptions (as opposed to runtime exceptions or unchecked exceptions), but also add a lot of consistency to your code base. People having learnt Spring’s JdbcTemplate can pretty easily start using Spring’s JdoTemplate or Spring’s HibernateTemplate–the approach to using those is similar for each one of them.

The most visible impact of the Spring template approach is the code reduction for for example JDBC. This is primarily because the checked exceptions are translated to runtime exceptions inside the template, removing the need to catch the exception in your mainline code. Other reasons are the transparent resource management and automatic synchronization with the currently running transaction. Of course it’s fairly easy to change a framework to use runtime exceptions natively instead of Spring having to do this and this is what for example Hibernate has started to do from version 3.0 onwards. Hibernate is not the only technology to do this–the Java Persistence API is also using runtime exceptions.