mirror of
https://github.com/spring-projects/spring-framework
synced 2026-06-08 17:33:33 +00:00
e0b1c0e614
Prior to this commit many imagedata elements were duplicated in order to configure PDF sizes. Since HTML generation is configured to ignore image scaling altogether this was unnecessary duplication. Issue: SPR-10033
157 lines
6.4 KiB
XML
157 lines
6.4 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<chapter xml:id="dao"
|
|
xmlns="http://docbook.org/ns/docbook" version="5.0"
|
|
xmlns:xl="http://www.w3.org/1999/xlink"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
|
xsi:schemaLocation="
|
|
http://docbook.org/ns/docbook http://www.docbook.org/xml/5.0/xsd/docbook.xsd
|
|
http://www.w3.org/1999/xlink http://www.docbook.org/xml/5.0/xsd/xlink.xsd">
|
|
<title>DAO support</title>
|
|
|
|
<section xml:id="dao-introduction">
|
|
<title>Introduction</title>
|
|
|
|
<para>The Data Access Object (DAO) support in Spring is aimed at making it
|
|
easy to work with data access technologies like JDBC, Hibernate, JPA or
|
|
JDO in a consistent way. This allows one to switch between the
|
|
aforementioned persistence technologies fairly easily and it also allows
|
|
one to code without worrying about catching exceptions that are specific
|
|
to each technology.</para>
|
|
</section>
|
|
|
|
<section xml:id="dao-exceptions">
|
|
<title>Consistent exception hierarchy</title>
|
|
|
|
<para>Spring provides a convenient translation from technology-specific
|
|
exceptions like <classname>SQLException</classname> to its own exception
|
|
class hierarchy with the <classname>DataAccessException</classname> as the
|
|
root exception. These exceptions wrap the original exception so there is
|
|
never any risk that one might lose any information as to what might have
|
|
gone wrong.</para>
|
|
|
|
<para>In addition to JDBC exceptions, Spring can also wrap
|
|
Hibernate-specific exceptions, converting them from proprietary, checked
|
|
exceptions (in the case of versions of Hibernate prior to Hibernate 3.0),
|
|
to a set of focused runtime exceptions (the same is true for JDO and JPA
|
|
exceptions). This allows one to handle most persistence exceptions, which
|
|
are non-recoverable, only in the appropriate layers, without having
|
|
annoying boilerplate catch-and-throw blocks and exception declarations in
|
|
one's DAOs. (One can still trap and handle exceptions anywhere one needs
|
|
to though.) As mentioned above, JDBC exceptions (including
|
|
database-specific dialects) are also converted to the same hierarchy,
|
|
meaning that one can perform some operations with JDBC within a consistent
|
|
programming model.</para>
|
|
|
|
<para>The above holds true for the various template classes in Springs
|
|
support for various ORM frameworks. If one uses the interceptor-based
|
|
classes then the application must care about handling
|
|
<classname>HibernateExceptions</classname> and
|
|
<classname>JDOExceptions</classname> itself, preferably via delegating to
|
|
<classname>SessionFactoryUtils</classname>'
|
|
<methodname>convertHibernateAccessException(..)</methodname> or
|
|
<methodname>convertJdoAccessException()</methodname> methods respectively.
|
|
These methods convert the exceptions to ones that are compatible with the
|
|
exceptions in the <literal>org.springframework.dao</literal> exception
|
|
hierarchy. As <classname>JDOExceptions</classname> are unchecked, they can
|
|
simply get thrown too, sacrificing generic DAO abstraction in terms of
|
|
exceptions though.</para>
|
|
|
|
<para>The exception hierarchy that Spring provides can be seen below.
|
|
(Please note that the class hierarchy detailed in the image shows only a
|
|
subset of the entire <classname>DataAccessException</classname>
|
|
hierarchy.)</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata align="center" fileref="images/DataAccessException.gif" format="PNG" width="400" />
|
|
</imageobject>
|
|
</mediaobject>
|
|
</section>
|
|
|
|
<section xml:id="dao-annotations">
|
|
<title>Annotations used for configuring DAO or Repository classes</title>
|
|
|
|
<para>The best way to guarantee that your Data Access Objects (DAOs) or
|
|
repositories provide exception translation is to use the
|
|
<interfacename>@Repository</interfacename> annotation. This annotation
|
|
also allows the component scanning support to find and configure your DAOs
|
|
and repositories without having to provide XML configuration entries for
|
|
them.</para>
|
|
|
|
<programlisting language="java"><emphasis role="bold">@Repository</emphasis>
|
|
public class SomeMovieFinder implements MovieFinder {
|
|
|
|
// ...
|
|
|
|
}</programlisting>
|
|
|
|
<para>Any DAO or repository implementation will need to access to a
|
|
persistence resource, depending on the persistence technology used; for
|
|
example, a JDBC-based repository will need access to a JDBC
|
|
<interfacename>DataSource</interfacename>; a JPA-based repository will need
|
|
access to an <interfacename>EntityManager</interfacename>. The easiest way
|
|
to accomplish this is to have this resource dependency injected using one of
|
|
the <interfacename>@Autowired,</interfacename>, <interfacename>@Inject</interfacename>,
|
|
<interfacename>@Resource</interfacename> or
|
|
<interfacename>@PersistenceContext</interfacename> annotations. Here is an
|
|
example for a JPA repository:</para>
|
|
|
|
<programlisting language="java">@Repository
|
|
public class JpaMovieFinder implements MovieFinder {
|
|
|
|
@PersistenceContext
|
|
private EntityManager entityManager;
|
|
|
|
// ...
|
|
|
|
}</programlisting>
|
|
|
|
<para>If you are using the classic Hibernate APIs than you can inject the
|
|
SessionFactory:</para>
|
|
|
|
<programlisting language="java">@Repository
|
|
public class HibernateMovieFinder implements MovieFinder {
|
|
|
|
private SessionFactory sessionFactory;
|
|
|
|
@Autowired
|
|
public void setSessionFactory(SessionFactory sessionFactory) {
|
|
this.sessionFactory = sessionFactory;
|
|
}
|
|
|
|
// ...
|
|
|
|
}</programlisting>
|
|
|
|
<para>Last example we will show here is for typical JDBC support. You
|
|
would have the <classname>DataSource</classname> injected into an
|
|
initialization method where you would create a
|
|
<classname>JdbcTemplate</classname> and other data access support classes
|
|
like <classname>SimpleJdbcCall</classname> etc using this
|
|
<classname>DataSource</classname>.</para>
|
|
|
|
<programlisting language="java">@Repository
|
|
public class JdbcMovieFinder implements MovieFinder {
|
|
|
|
private JdbcTemplate jdbcTemplate;
|
|
|
|
@Autowired
|
|
public void init(DataSource dataSource) {
|
|
this.jdbcTemplate = new JdbcTemplate(dataSource);
|
|
}
|
|
|
|
// ...
|
|
|
|
}</programlisting>
|
|
|
|
<note>
|
|
<para>Please see the specific coverage of each persistence technology
|
|
for details on how to configure the application context to take
|
|
advantage of these annotations.</para>
|
|
</note>
|
|
|
|
<para></para>
|
|
</section>
|
|
</chapter>
|