29-03-2012, 12:49 PM
Object Relational Mapping (ORM) data access
important 23.docx (Size: 94.17 KB / Downloads: 64)
Introduction
The Spring Framework provides integration with Hibernate, JDO, Oracle TopLink, iBATIS SQL Maps and
JPA: in terms of resource management, DAO implementation support, and transaction strategies. For example
for Hibernate, there is first-class support with lots of IoC convenience features, addressing many typical
Hibernate integration issues. All of these support packages for O/R (Object Relational) mappers comply with
Spring's generic transaction and DAO exception hierarchies. There are usually two integration styles: either
using Spring's DAO 'templates' or coding DAOs against plain Hibernate/JDO/TopLink/etc APIs. In both cases,
DAOs can be configured through Dependency Injection and participate in Spring's resource and transaction
management.
Spring adds significant support when using the O/R mapping layer of your choice to create data access
applications. First of all, you should know that once you started using Spring's support for O/R mapping, you
don't have to go all the way. No matter to what extent, you're invited to review and leverage the Spring
approach, before deciding to take the effort and risk of building a similar infrastructure in-house. Much of the
O/R mapping support, no matter what technology you're using may be used in a library style, as everything is
designed as a set of reusable JavaBeans. Usage inside a Spring IoC container does provide additional benefits
in terms of ease of configuration and deployment; as such, most examples in this section show configuration
inside a Spring container.
Hibernate
We will start with a coverage of Hibernate 3 in a Spring environment, using it to demonstrate the approach that
Spring takes towards integrating O/R mappers. This section will cover many issues in detail and show different
variations of DAO implementations and transaction demarcation. Most of these patterns can be directly
translated to all other supported ORM tools. The following sections in this chapter will then cover the other
ORM technologies, showing briefer examples there.
Note: As of Spring 2.5, Spring requires Hibernate 3.1 or higher. Neither Hibernate 2.1 nor Hibernate 3.0 are
supported anymore.
12.2.1. Resource management
Typical business applications are often cluttered with repetitive resource management code. Many projects try
to invent their own solutions for this issue, sometimes sacrificing proper handling of failures for programming
convenience. Spring advocates strikingly simple solutions for proper resource handling, namely IoC via
templating; for example infrastructure classes with callback interfaces, or applying AOP interceptors. The
infrastructure cares for proper resource handling, and for appropriate conversion of specific API exceptions to
an unchecked infrastructure exception hierarchy. Spring introduces a DAO exception hierarchy, applicable to
any data access strategy. For direct JDBC, the JdbcTemplate class mentioned in a previous section cares for
connection handling, and for proper conversion of SQLException to the DataAccessException hierarchy,
including translation of database-specific SQL error codes to meaningful exception classes. It supports both
JTA and JDBC transactions, via respective Spring transaction managers.
Implementing Spring-based DAOs without callbacks
As alternative to using Spring's HibernateTemplate to implement DAOs, data access code can also be written
in a more traditional fashion, without wrapping the Hibernate access code in a callback, while still respecting
and participating in Spring's generic DataAccessException hierarchy. The HibernateDaoSupport base class
offers methods to access the current transactional Session and to convert exceptions in such a scenario; similar
methods are also available as static helpers on the SessionFactoryUtils class.
Transaction management strategies
Both TransactionTemplate and TransactionInterceptor delegate the actual transaction handling to a
PlatformTransactionManager instance, which can be a HibernateTransactionManager (for a single
Hibernate SessionFactory, using a ThreadLocal Session under the hood) or a JtaTransactionManager
(delegating to the JTA subsystem of the container) for Hibernate applications. You could even use a custom
PlatformTransactionManager implementation. So switching from native Hibernate transaction management to
JTA, such as when facing distributed transaction requirements for certain deployments of your application, is
just a matter of configuration. Simply replace the Hibernate transaction manager with Spring's JTA transaction
implementation. Both transaction demarcation and data access code will work without changes, as they just use
the generic transaction management APIs.