- 概述
- Spring的DAO理念
- 统一的异常体系
- 统一的数据访问模板
- 使用模板和回调机制
- 模板类
- 数据源
- 配置数据源
- DBCP数据源
- C3P0数据源
- 获取JNDI数据源
- Spring的数据源实现类
- 配置数据源
- 总结
概述
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进行数据操作的简单代码,已经尽可能的简化了整个处理的过程
代码语言:javascript复制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数据库连接池解读
简略配置如下:
代码语言:javascript复制"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-数据库连接池解读
一个简单的配置
代码语言:javascript复制<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="driverClass">
<value>oracle.jdbc.driver.OracleDrivervalue>
property>
<property name="jdbcUrl">
<value>jdbc:oracle:thin:@ip:port:instanceNamevalue>
property>
<property name="user">
<value>artisanvalue>
property>
<property name="password">
<value>artisanvalue>
property>
bean>
获取JNDI数据源
Java Naming and Directory Interface (Java命名和目录服务接口)
如果应用配置在高性能的应用服务器比如weblogic/websphere等,则可能希望使用应用本身提供的数据源。 应用服务器的数据源使用JNDI开放调用者使用,Spring为此专门提供了引用JNDI数据源的JndiObjectFactoryBean,我们来看一个简单的配置
代码语言:javascript复制id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/jdbc/自定义name"/>
通过jndiName指定引用的JNDI数据源名称
Spring为JavaEE资源提供了一个jee命名空间,通过jee命名空间,可以有效的简化Java EE资源的引用, 如下所示:
代码语言:javascript复制<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的简单使用。
代码语言:javascript复制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。 如下
代码语言:javascript复制 -- Initialization for data source -->
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"/>
总结
不管采用何种持久化技术,都需要定义数据源。Spring附带了两个数据源的实现类包,你可以自行选择进行定义。 在实际部署时,我们可能会直接采用应用服 务器本身提供的数据源, 这时,则可以通过JndiObjectFactoryBean或jee命名空间引用JNDI中的数据源