Data Access with the Spring Framework
(featuring Hibernate examples)

Juergen Hoeller

July 2003

0. Preface: Spring Benefits for Hibernate Users
Spring's lightweight bean container offers IoC-style wiring up of business objects, DAOs, and resources like JDBC DataSources and Hibernate SessionFactories. Such an XML-defined application context is a powerful alternative to manually managed singletons or factories that parse their configuration from custom properties files. As non-intrusiveness is a central goal, such Spring-configured application beans do not need to depend on Spring interfaces or classes but get configured via their bean properties. This concept can be applied in any environment, be it a J2EE web app, a desktop app, or even an applet.

In the context of Hibernate, Spring's generic transaction management for DAOs is of particular interest. The goal is to separate data access and transaction demarcation aspects to allow for reusable transactional business objects that are not tied to any specific data access or transaction strategy. Demarcation can either happen programmatically via TransactionTemplate, or declaratively via the AOP TransactionInterceptor. Both native Hibernate / JDBC transactions and JTA are supported as strategies out-of-the-box. This is a viable alternative to local Stateless Session Beans.

Spring's HibernateTemplate offers a simple way to implement Hibernate-based DAOs without caring about handling Session instances or participating in transactions. No need for try-catch blocks, no need for transaction checks. A simple Hibernate access method can be a one-liner! Combining heterogeneous DAOs works seamlessly, both in terms of DAO interfaces and participating in transactions. For example, certain DAOs can be implemented on plain JDBC, preferably via Spring's JdbcTemplate to avoid manual exception handling.

You can use a lot of Spring's features respectively classes in a library style, as everything is designed as a set of reusable JavaBeans. Don't be discouraged by the fact that Spring can serve as full application framework too! The application context concept is an additional benefit, not a requirement for using other Spring features. In any case, you're invited to review and leverage the Spring approach, no matter to what extent, before deciding to take the effort and risk of building such infrastructure in-house.