Spring JDBC-Spring对DAO的支持
概述
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进行数据操作的简单代码，已经尽可能的简化了整个处理的过程
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数据库连接池解读
简略配置如下：
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-数据库连接池解读
一个简单的配置
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,我们来看一个简单的配置
1
2
3
通过jndiName指定引用的JNDI数据源名称
Spring为JavaEE资源提供了一个jee命名空间，通过jee命名空间，可以有效的简化Java EE资源的引用， 如下所示：
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。 如下
1
2
3
4
5
6
7
8
总结
不管采用何种持久化技术，都需要定义数据源。Spring附带了两个数据源的实现类包，你可以自行选择进行定义。 在实际部署时，我们可能会直接采用应用服 务器本身提供的数据源， 这时，则可以通过JndiObjectFactoryBean或jee命名空间引用JNDI中的数据源
JDBC Spring
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
推荐文章
最近发表
