概述

Spring对多个持久化技术提供了集成支持，包括Hibernate、MyBatis、JPA、JDO。 此外Spring还提供了一个简化JDBC API操作的Spring JDBC框架。

Spring面向DAO制定了一个通用的异常体系，屏蔽了持久化技术的异常，使业务层和具体的持久化技术实现解耦。

另外，Spring提供了模板类简化各种持久化技术的使用。

通用的异常体系和模板类是Spring整合各种持久化技术的不二法门。

Spring的DAO理念

DAO（DATA Acces Object）是用于访问数据的对象，虽然大多数情况下存储在数据库中，但是也可以存放在文件或者LDAP（轻量目录访问协议，Lightweight Directory Access Protocol）中。 DAO不但屏蔽了数据存储最重介质的不同，也屏蔽了具体的实现技术的不同。

早起，JDBC是主流选择，近些年，数据库持久化技术得到了长足的发展。 只要为数据访问定义好DAO接口，并使用具体的实现技术实现DAO接口的功能，就可以在不同的实现技术之间平滑的切换。

我们来举个例子 ： 如下是一个典型的DAO应用实例，在USerDAO中定义访问User数据对象的接口方法，业务层通过UserDao操作数据，并使用具体的持久化技术实现USerDao接口方法，这样就实现了业务层和具体的持久化技术之间的解耦

提供DAO抽象层的好处：

• 首先可以很容易的构造模拟对象，方便单元测试的开展
• 其次在使用切面会有更多的选择，可以使用JDK动态代理，又可以使用CGLib动态代理

Spring本质上希望以统一的方式整合底层的持久化技术，即以统一的方式进行调用及事务管理，避免让具体的实现侵入到业务层的代码中。 由于每种持久化技术都有各自的异常体系，所以Spring提供了统一的异常体系，使不同异常体系的阻抗得以消弭，方便定义出和具体实现技术无关的DAO接口，以及整合到相同的事务管理体系中。

统一的异常体系

统一的异常体系是整合不同的持久化技术的关键。 Spring提供了一套和实现技术无关的、面向DAO层语义的异常体系，并通过转换器将不同持久化技术的异常转换成Spring的异常

很多正统API或者框架中，检查型异常被过多的使用，以致在使用API时，代码中充斥了大量的try/cath样板式的代码。这样就导致一堆异常处理的代码喧宾夺主侵入到业务代码中，破坏了代码的整洁和优雅。

Spring在org.springframework.dao包中提供了一套完备优雅的DAO异常体系，
这些异常都继承于DataAccessException ， 而DataAccessException本身又继承于NestedRuntimeException, NestedRuntimeException异常以嵌套的方式封装了源异常。 因此，虽然不同的持久化技术的特定异常被转换到Spring的DAO异常体系中，但原始的异常信息并不会丢失，我们依然可以通过getCaucse()方法获取原始的异常信息。

JDBC/Mybatis的异常转换器为SQLErrorCodeSQLExceptionTranslator

Spring以分类手法建立了异常分类目录 ，如下所示（为第一层次的异常类，每个异常类下都可能有众多子异常类），一方面可以使开发者从底层细如针麻的技术细节中脱离出来，另一方面可以选择感兴趣的异常加以处理。

统一的数据访问模板

Spring为支持持久化技术分别提供了模板访问的方式，降低了使用各种持久化技术的难度，因此可以大幅度的提供开发效率。

使用模板和回调机制

我们先看一段使用JDBC进行数据操作的简单代码，已经尽可能的简化了整个处理的过程

public void saveUser(User user) {
        Connection connection = null;
        PreparedStatement stmt = null;

        try {
            // 获取连接
            connection = DriverManager.getConnection(url, user, password);

            // 启动事物
            connection.setAutoCommit(false);

            // 业务操作
            stmt = connection
                    .prepareStatement("insert into user(id ,name) values(?,?)");
            stmt.setLong(1, user.getUserId());
            stmt.setString(2, user.getUserName());

            // 执行提交
            stmt.execute();

            // 提交事务
            connection.commit();

        } catch (Exception e) {
            // 回滚
            connection.rollback();
        } finally {
            // 释放资源
            stmt.close();
            connection.close();
        }
    }
  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
  
30
  
31
  
32
 

如上代码所述，JDBC访问数据按照如下流程

• 获取连接
• 开启事务（如果有需要）
• 执行具体的数据访问操作
• 提交/回滚事务
• 关闭资源

我们可以看到只有具体的业务操作才是我们关心的， Spring将这些相同的数据访问流程固化到模板中，并将数据访问中固定和变化的部分分开，同时保证模板类是线程安全的，以便多个数据访问线程共享同一个模板实例。变化的部分通过回调接口开放出来，用于定义数据访问和结果返回的操作。 （如下图）

这样我们只需要编写回调接口，并调用模板类进行数据访问，就可以得到我们期待的结果：数据访问成功执行，前置和后置的样板化工作也按照顺序正确执行，在提供开发效率的同时保证了资源使用的正确性，彻底消除了因为忘记进行资源释放而引起的资源泄漏问题。

模板类

Spring为各种支持的持久化技术都提供了简化操作的模板和回调，在回调中编写具体的数据操作逻辑，使用模板执行数据操作，在Spring中这是典型的数据操作模式。

我们来了解下Spring为不同的持久化技术所提供的模板类

如果直接使用模板类，则演需要在DAP中定义一个模板对象并提供数据资源。 Spring为每种持久化技术都提供了支持列，支持类中已完成了这样的功能。 这样我们只需要扩展这些支持类，就可以直接编写实际的数据访问逻辑，因此更加方便。

这些类都是继承于dao.support.DaoSupport类， DaoSupport实现了InitializingBean接口，在afterPropertiesSet（）接口中检查模板对象和数据源是否被正确设置，否则将抛出异常。

所有的支持类都是abstract，其目的是希望被继承使用，而非直接使用

数据源

在Spring中，不但可以通过JNDI获取应用服务器的数据源，也可以在Spring容器中配置数据源。 此外还可以通过代码的方式创建一个数据源，以便进行无容器依赖的单元测试。

配置数据源

Spring在第三方依赖包中包含了2个数据源的实现类包

• Apache的DBCP
• C2P0

我们可以在Spring配置文件中利用二者中的任何一个配置数据源。

DBCP数据源

因篇幅原因，另开一篇 Apache-DBCP数据库连接池解读

简略配置如下：

<bean id="dataSourcePR" class="org.apache.commons.dbcp.BasicDataSource" 
        destroy-method="close"
        p:driverClassName="${jdbc.driverClassNamePR}"
        p:url="${jdbc.urlPR}"
        p:username="${jdbc.usernamePR}"
        p:password="${jdbc.passwordPR}" />
  

 

  
1
  
2
  
3
  
4
  
5
  
6
 

BasicDataSource提供了close（）方法关闭数据源，所以必须设定destroy-method=”close”属性，以便Spring容器关闭时，数据源能够正常关闭。

假设数据库为MySQL，如果配置不当，会发生经典的“8小时为” 。

原因是MySQL在默认情况下发现一个连接空闲时间超过8小时，则会在数据库端自动关闭这个连接。 而数据源并不知道这个连接已经被数据库关闭了，当它将这个无用的连接返回个某个DAO时，DAO就会抛出无法获取Connection的异常。

如果采用DBCP默认配置，由于testOnBorrow默认为true，数据源在将连接交给DAO之前，会事先检查这个连接是否良好，如果连接有问题（在数据库端被关闭），则回取一个其他的连接给DAP，并不会有“8小时问题”。 但是这样每次都检查有效性，在高并发的应用中会带来性能问题。

一种推荐的高效方式是： 将testOnBorrow设置为false，而将testWhielIdel设置为true,再设置好 timeBetweenEvictionRunsMillis的值。 这样DBCP将通过一个后台线程定时的对空闲连接进行检测，当发现无用的空闲连接（那些被数据库关闭的连接）时，就会将它们清掉，只要将timeBetweenEvictionRunsMillis设置为小于8小时，那些被MySQL关闭的空闲连接就可以被清除出去，从而避免“8小时问题”

当然，MySQL本身可以通过调整interactive-timeout(以秒为单位)配置参数，更改空闲连接的过期时间， 所以在设置timeBetweenEvictionRunsMillis值时，必须首先获知MySQL空闲连接的最大过期时间。

C3P0数据源

因篇幅原因，另开一篇 C3P0-数据库连接池解读

一个简单的配置

<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">     
    <property name="driverClass">     
        <value>oracle.jdbc.driver.OracleDriver</value>     
    </property>     
    <property name="jdbcUrl">                
        <value>jdbc:oracle:thin:@ip:port:instanceName</value>     
     </property>     
    <property name="user">     
        <value>artisan</value>     
    </property>     
    <property name="password">     
        <value>artisan</value>     
    </property>     
</bean> 
  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
 

获取JNDI数据源

Java Naming and Directory Interface （Java命名和目录服务接口）

如果应用配置在高性能的应用服务器比如weblogic/websphere等,则可能希望使用应用本身提供的数据源。 应用服务器的数据源使用JNDI开放调用者使用，Spring为此专门提供了引用JNDI数据源的JndiObjectFactoryBean,我们来看一个简单的配置

<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:comp/env/jdbc/自定义name"/>
</bean>
  

 

  
1
  
2
  
3
 

通过jndiName指定引用的JNDI数据源名称

Spring为JavaEE资源提供了一个jee命名空间，通过jee命名空间，可以有效的简化Java EE资源的引用， 如下所示：

<beans xmlns=http://www.springframework.org/schema/beans       
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance       
xmlns:jee=http://www.springframework.org/schema/jee       
xsi:schemaLocation="http://www.springframework.org/schema/beans        
http://www.springframework.org/schema/beans/spring-beans.xsd        
http://www.springframework.org/schema/jee       
http://www.springframework.org/schema/jee/spring-jee.xsd">         
<jee:jndi-lookup id="dataSource" jndi-name=" java:comp/env/jdbc/自定义name"/>         
</beans>   
  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
 

Spring的数据源实现类

Spring本身也提供了一个简单的数据源实现类org.springframework.jdbc.datasource.DriverManagerDataSource

这个类实现了javax.sql.DataSource接口， 但 它并没有提供池化连接的机制，每次调用getConnection()获取新连接时，只是简单地创建一个新的连接。

因此，这个数据源类比较适合在单元测试 或简单的独立应用中使用，因为它不需要额外的依赖类。

下面，我们来看一下DriverManagerDataSource的简单使用。

DriverManagerDataSource ds = new DriverManagerDataSource ();         
ds.setDriverClassName("com.mysql.jdbc.Driver");         
ds.setUrl("jdbc:mysql://localhost:3309/sampledb");         
ds.setUsername("artisan");         
ds.setPassword("123456");         
Connection actualCon = ds.getConnection();   
  

 

  
1
  
2
  
3
  
4
  
5
  
6
 

当然，我们也可以通过配置的方式直接使用DriverManagerDataSource。 如下

 <!-- Initialization for data source -->
   <bean id = "dataSource" 
      class = "org.springframework.jdbc.datasource.DriverManagerDataSource">
      <property name = "driverClassName" value = "com.mysql.jdbc.Driver"/>
      <property name = "url" value = "jdbc:mysql://localhost:3309/sampledb"/>
      <property name = "username" value = "artisan"/>
      <property name = "password" value = "123456"/>
   </bean>
  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
 

总结

不管采用何种持久化技术，都需要定义数据源。Spring附带了两个数据源的实现类包，你可以自行选择进行定义。 在实际部署时，我们可能会直接采用应用服 务器本身提供的数据源， 这时，则可以通过JndiObjectFactoryBean或jee命名空间引用JNDI中的数据源

文章来源: artisan.blog.csdn.net，作者：小小工匠，版权归原作者所有，如需转载，请联系作者。

原文链接：artisan.blog.csdn.net/article/details/78003221