How Spring can Leverage any ORM

I was previously working with Spring with Hibernate (2.3) Combination. It was really painful because hibernate was throwing all the exceptions as checked exceptions and we were forced to catch all the exceptions in the Service Layer. But now a days it is very simple as we can catch the exceptions as Throwable in Service Layer and can use an Interceptor to log those message and rethrow as application specific exceptions. I came across a good article about the Spring leveraging any ORM and thought of adding its content into my blog with the reference to the source site.

In a typical Spring architecture, DAOs are effectively Strategy Pattern objects, isolating service layer objects from the technology specifics of obtaining and saving persistent objects.

Spring supports a range of ORM tools and persistence frameworks, including (but not limited to) TopLink, Hibernate, JDO (Java Data Objects), iBATIS SQL Maps, and Apache OJB (ObjectRelational Bridge).

Spring provides a consistent approach to working with all these tools, but doesn't attempt to completely abstract the ORM tool, because doing so would be counterproductive. Thus, for example, implementations of DAO interfaces will use the native query API of the ORM tool: Spring does not attempt to create a query abstraction, which would be less powerful than that of leading ORM products.

How Spring can Leverage any ORM ?

For DAO interfaces to be independent of the underlying persistence technology, we need to solve some crucial issues. Spring provides important help here, especially in the areas of exception handling; resource acquisition and release; and transaction management. Spring exception handling: Two key features of Spring's exception handling enable it to remain independent of the underlying persistence technology. First, it uses a class-based hierarchy of generic data access exceptions (Figure shows the most important classes in the hierarchy) that can leverage any underlying ORM's exception mechanisms. The exception hierarchy can easily be extended. Thus, for example, you can write service layer code to handle DataIntegrityViolationException (violation of a constraint such as a primary key constraint), without concern as to the data access tool in use, which may be JDBC, TopLink, JDO, Hibernate or another supported framework. This hierarchy is even extensible without modifying Spring code, if you wish to add mappings to error conditions unique to your database or persistence tool.

Secondly, Spring's exception handling approach uses unchecked exceptions. Using unchecked exceptions works particularly well in conjunction with an exception hierarchy, because it is only necessary to catch a particular subclass that may be recoverable. Catching subclasses of checked exceptions is less useful, since the base class still needs to be caught. (Note that JDBC was always something of an odd API out, in terms of using checked exceptions: TopLink and JDO, for example, both use unchecked exceptions. In version 3, Hibernate will switch from checked to unchecked exceptions.)

Resource acquisition and release: One of the major challenges of working with any data access technology is that resources such as JDBC connections or ORM sessions must be acquired and released correctly even in the event of errors.

Spring solves the problem of resource acquisition and release by using a callback approach. The framework is responsible for acquiring and releasing resources, while the application developer implements code in a callback method to perform the necessary persistence operation with the desired resource. Thus application developers focus on the unique needs of their application, rather than writing plumbing code.

Helper classes that provide this functionality are termed templates, and Spring provides a consistent approach across many APIs where such resource acquisition and release is a problem, such as JDBC, JNDI and JMS.

Transaction management and thread binding: Spring's resource acquisition and release strategy is integrated with its transaction management support. It's important to get the same resource for every operation in the same transaction. While JTA and JCA may provide support for this in a full-blown J2EE environment (depending on the persistence tool), Spring provides support for this in any environment, including J2SE environments. The necessary Spring configuration is also simpler than JCA configuration.

Spring does this by binding resources such as JDBC connections or TopLink or Hibernate Sessions to the current thread. Many application developers have implemented such support in their own applications. However, the Spring solution not only has the merit of being far more sophisticated than typical in-house solutions (with support for transaction suspension and many other complex-to-implement value adds), but eliminates the need to write and maintain such custom code. Again, generic concerns are best given a generic solution.

Source: http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk9.html