Data Access Overview
Jetspeed-2 RDBMS component provide some of level of abstraction from the underlying persistence mechanism.
Data Access Using Object Relational Mapping
Jetspeed-2 uses object relational mapping as the underlying technology for persistence. By default,
Apache OJB is used as an ORM engine. In order to minimize Jetspeed-2
OJB dependencies, the InitablePersistenceBrokerDaoSupport
provides a layer of abstraction that minimizes
the dependencies on a specific ORM engine. The class diagram below illustration the Jetspeed-2 implementation classes
that leverage InitablePersistenceBrokerDaoSupport
:
The InitablePersistenceBrokerDaoSupport
extends org.springframework.orm.ojb.support.PersistenceBrokerDaoSupport
.
Spring ORM Support
Spring's adds significant support when using the O/R mapping layer of your choice to create data access applications. The
InitablePersistenceBrokerDaoSupport
extends spring layer of abstraction for persistence support, specifically the
OJB PersistenceBroker
API support.
Using such a layer of abstraction has many advantages. Some of the advantages outlined in Spring's documentation are:
- Ease of testing. Spring's inversion of control approach makes it easy to swap the implementations and config locations of persistence manager instances,
JDBC DataSources, transaction managers, and mapper object implementations (if needed). This makes it much easier to isolate and test each piece of
persistence-related code in isolation.
- Common data access exceptions. Spring can wrap exceptions from you O/R mapping tool of choice, converting them from proprietary (potentially checked) exceptions
to a common runtime DataAccessException hierarchy. This allows you to handle most persistence exceptions, which are non-recoverable, only in the appropriate layers,
without annoying boilerplate catches/throws, and exception declarations. You can still trap and handle exceptions anywhere you need to. Remember that JDBC exceptions
(including DB specific dialects) are also converted to the same hierarchy, meaning that you can perform some operations with JDBC within a consistent programming model.
- General resource management. Spring application contexts can handle the location and configuration of persistence managers instances, JDBC DataSources,
and other related resources. This makes these values easy to manage and change. Spring offers efficient, easy and safe handling of persistence resources.
- Integrated transaction management. Spring allows you to wrap your O/R mapping code with either a declarative, AOP style method interceptor,
or an explicit 'template' wrapper class at the Java code level. In either case, transaction semantics are handled for you, and proper transaction handling (rollback, etc)
in case of exceptions is taken care of. As discussed below, you also get the benefit of being able to use and swap various transaction managers, without your ORM specific code being affected:
for example, between local transactions and JTA, with the same full services (such as declarative transactions) available in both scenarios. As an additional benefit,
JDBC-related code can fully integrate transactionally with the code you use to do O/R mapping. This is useful for data access that's not suitable for O/R mapping,
such as batch processing or streaming of BLOBs, which still needs to share common transactions with O/R mapping operations.
- To avoid vendor lock-in, and allow mix-and-match implementation strategies.