Summary

Spring provides highly sophisticated support for a variety of O/R mapping solutions, ranging from iBATIS SQL Maps to full-blown transparent persistence tools such as Hibernate, JDO, and TopLink. The most important areas addressed are data access object implementation and transaction management; there are also a variety of further support classes for special features of certain tools.

The Spring philosophy, in data access as elsewhere, is that there is no single correct answer for data access. Instead, we aim to provide a consistent overall architectural template, within which you can choose whatever persistence solution best fits your needs.

Spring provides a consistent model for resource and transaction management, no matter which O/R mapping tool you choose. Connections are always managed under the hood, and transactions are always demarcated via Spring's generic transaction demarcation facilities. Furthermore, all resource exceptions are converted to Spring's generic DataAccessException hierarchy, allowing DAOs to throw a generic exception rather than a tool-specific one.

While providing many convenience operations for each tool, Spring offers the full power of the underlying resource if you need it, through callbacks that give access to the native Hibernate Session, JDO PersistenceManager, or TopLink Session, respectively. In general, Spring does not aim to abstract the data access operations of the actual tool used: Instead, it separates the transaction management concern from the data access operations and provides implicit connection handling, including transaction synchronization.

All of Spring's O/R mapping support can either work with a corresponding local transaction strategy, executing transactions for a single target database, or with JTA transactions, delegating to the J2EE server for distributed transaction coordination (potentially spanning multiple resources). The main advantage of the local strategies is that they can work in any environment, that is, both within and outside a J2EE server — as long as you are accessing a single target database.

As much as possible, Spring's O/R mapping support isolates dependencies on a specific O/R mapping tool within an application's codebase. Neither transaction demarcation nor DAO usage involve dependencies on a concrete tool, as they purely work with Spring concepts. Only DAO implementations depend on a specific persistence API; in principle, those can quite easily be replaced with implementations for a different tool — if you ever need to switch an application from one O/R mapper to another. However, there are semantic differences between the persistence strategies, in particular with respect to the lifecycle of persistent objects. Be aware that callers might rely on specific behavior that might vary between different tools.

Important 

The main areas addressed by Spring's O/R mapping support are data access object implementation and transaction management. Resources are consistently managed under the hood, and exceptions automatically translated to Spring's DataAccessException hierarchy.

Despite the common handling, DAO implementations can still work with the full power of the underlying persistence tool. Spring does not aim to provide an abstraction over the native API of Hibernate or JDO. Instead, it offers a consistent setup and usage style for all supported strategies, while still allowing DAOs to use the native query and operation style of each tool.

We feel that by using Spring's data access abstraction — whatever your choice of O/R mapping tool — you will gain much convenience, eliminate common causes of errors, yet sacrifice none of the power of the ORM tool itself.