Spring JDBC-Spring对DAO的支持

标签: springdao
1629人阅读 评论(0) 收藏 举报
分类:

概述

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();
        }
    }

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

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

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

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

这里写图片描述


模板类

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

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

ORM持久化技术 模板类
JDBC/Mybatis org.springframework.jdbc.core.JdbcTemplate
Hibernate org.springframework.orm.hibernate3/4/5.HibernateTemplate
JPA org.springframework.orm.jpa.JpaTemplate
JDO org.springframework.orm.jdo.JdoTemplate

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

ORM持久化技术 支持类
JDBC/Mybatis org.springframework.jdbc.core.JdbcDaoSupport
Hibernate org.springframework.orm.hibernate3/4/5.HibernateDaoSupport
JPA org.springframework.orm.jpa.JpaDaoSupport
JDO org.springframework.orm.jdo.JdoDaoSupport

这些类都是继承于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}" />

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> 

获取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>

通过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>   

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();   

当然,我们也可以通过配置的方式直接使用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>

总结

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

1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1122266次
    • 积分:16909
    • 等级:
    • 排名:第676名
    • 原创:452篇
    • 转载:0篇
    • 译文:5篇
    • 评论:144条
    WeChat
      欢迎关注我的公众号,干货只有干货,还有更多惊喜和资源在等着你
    博客专栏