摘要 J2EE应用程序中的业务组件通常使用JDBC API访问和更改关系数据库中的持久数据。这经常导致持久性代码与业务逻辑发生混合，这是一种不好的习惯。数据访问对象（DAO）设计模式通过把持久性逻辑分成若干数据访问类来解决这一问题。
本文是一篇关于DAO设计模式的入门文章，突出讲述了它的优点和不足之处。另外，本文还介绍了Spring 2.0 JDBC/DAO框架并示范了它如何妥善地解决传统DAO设计中的缺陷。
传统的DAO设计
数据访问对象（DAO）是一个集成层设计模式，如Core J2EE Design Pattern 图书所归纳。它将持久性存储访问和操作代码封装到一个单独的层中。本文的上下文中所提到的持久存储器是一个RDBMS.
这一模式在业务逻辑层和持久存储层之间引入了一个抽象层，如图1所示。业务对象通过数据访问对象来访问RDBMS（数据源）。抽象层改善了应用程序代码并引入了灵活性。理论上，当数据源改变时，比如更换数据库供给商或是数据库的类型时，仅需改变数据访问对象，从而把对业务对象的影响降到最低。
图1. 应用程序结构，包括DAO之前和之后的部分
讲解了DAO设计模式的基础知识，下面将编写一些代码。下面的例子来自于一个公司域模型。简而言之，这家公司有几位员工工作在不同的部门，如销售部、市场部以及人力资源部。为了简单起见，我们将集中讨论一个称作“雇员”的实体。
针对接口编程
DAO设计模式带来的灵活性首先要归功于一个对象设计的最佳实践：针对接口编程（P2I）。这一原则规定实体必须实现一个供调用程序而不是实体自身使用的接口。因此，可以轻松替换成不同的实现而对客户端代码只产生很小的影响。
我们将据此使用findBySalaryRange（）行为定义Employee DAO接口，IEmployeeDAO.业务组件将通过这个接口与DAO交互：
import Java.util.Map;
public interface IEmployeeDAO {
//SQL String that will be executed
public String FIND_BY_SAL_RNG = "SELECT EMP_NO, EMP_NAME, "
+ "SALARY FROM EMP WHERE SALARY = ？ AND SALARY = ？";
//Returns the list of employees who fall into the given salary
//range. The input parameter is the immutable map object
//oBTained from the HttpServletRequest. This is an early
//refactoring based on "IntrodUCe Parameter Object"
public List findBySalaryRange(Map salaryMap);
}
提供DAO实现类
接口已经定义，现在必须提供Employee DAO的具体实现，EmployeeDAOImpl：
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import com.bea.dev2dev.to.EmployeeTO;
public class EmployeeDAOImpl implements IEmployeeDAO{
public List findBySalaryRange(Map salaryMap)
{
Connection conn = null;
PreparedStatement pstmt = null;
ResultSet rs = null;
List empList = new ArrayList();
//Transfer Object for inter-tier data transfer
EmployeeTO tempEmpTO = null;
try{
//DBUtil - helper classes that retrieve connection from pool
conn = DBUtil.getConnection();
pstmt = conn.prepareStatement(FIND_BY_SAL_RNG);
pstmt.setDouble(1, Double.valueOf( (String)
salaryMap.get("MIN_SALARY") );
pstmt.setDouble(2, Double.valueOf( (String)
salaryMap.get("MIN_SALARY") );
rs = pstmt.executeQuery();
int tmpEmpNo = 0;
String tmpEmpName = "";
double tmpSalary = 0.0D;
while (rs.next()){
tmpEmpNo = rs.getInt("EMP_NO");
tmpEmpName = rs.getString("EMP_NAME");
tmpSalary = rs.getDouble("SALARY");
tempEmpTO = new EmployeeTO(tmpEmpNo,
tmpEmpName,
tmpSalary);
empList.add(tempEmpTO);
}//end while
}//end try
catch (SQLException sqle){
throw new DBException(sqle);
}//end catch
finally{
try{
if (rs != null){
rs.close();
}
}
catch (SQLException sqle){
throw new DBException(sqle);
}
try{
if (pstmt != null){
pstmt.close();
}
}
catch (SQLException sqle){
throw new DBException(sqle);
}
try{
if (conn != null){
conn.close();
}
}
catch (SQLException sqle){
throw new DBException(sqle);
}
}//end of finally block
return empList;
}//end method findBySalaryRange
}
上面的清单说明了DAO方法的一些要点：
它们封装了所有与JDBC API的交互。假如使用像Kodo或者Hibernate的O/R映射方案，则DAO类可以将这些产品的私有API打包。
它们将检索到的数据打包到一个与JDBC API无关的传输对象中，然后将其返回给业务层作进一步处理。
它们实质上是无状态的。唯一的目的是访问并更改业务对象的持久数据。
（本文来源于图老师网站，更多请访问http://m.tulaoshi.com/bianchengyuyan/）在这个过程中，它们像SQLException一样捕捉任何底层JDBC API或数据库报告的错误（例如，数据库不可用、错误的SQL句法）。DAO对象再次使用一个与JDBC无关的自定义运行时异常类DBException，通知业务对象这些错误。
它们像Connection和PreparedStatement对象那样，将数据库资源释放回池中，并在使用完ResultSet游标之后，将其所占用的内存释放。
因此，DAO层将底层的数据访问API抽象化，为业务层提供了一致的数据访问API.
构建DAO工厂
DAO工厂是典型的工厂设计模式实现，用于为业务对象创建和提供具体的DAO实现。业务对象使用DAO接口，而不用了解实现类的具体情况。DAO工厂带来的依靠反转（dependency inversion）提供了极大的灵活性。只要DAO接口建立的约定未改变，那么很轻易改变DAO实现（例如，从straight JDBC实现到基于Kodo的O/R映射），同时又不影响客户的业务对象：
public class DAOFactory {
private static DAOFactory daoFac;
static{
daoFac = new DAOFactory();
}
private DAOFactory(){}
public DAOFactory getInstance(){
return daoFac;
}
public IEmployeeDAO getEmployeeDAO(){
return new EmployeeDAOImpl();
}
}
与业务组件的协作
现在该了解DAO怎样适应更复杂的情形。如前几节所述，DAO与业务层组件协作获取和更改持久业务数据。下面的清单展示了业务服务组件及其与DAO层的交互：
public class EmployeeBusinessServiceImpl implements
IEmployeeBusinessService {
public List getEmployeesWithinSalaryRange(Map salaryMap){
IEmployeeDAO empDAO = DAOFactory.getInstance()
.getEmployeeDAO();
List empList = empDAO.findBySalaryRange(salaryMap);
return empList;
}
}
交互过程十分简洁，完全不依靠于任何持久性接口（包括JDBC）。
问题
DAO设计模式也有缺点：
代码重复：从EmployeeDAOImpl清单可以清楚地看到，对于基于JDBC的传统数据库访问，代码重复（如上面的粗体字所示）是一个主要的问题。一遍又一遍地写着同样的代码，明显违反了基本的面向对象设计的代码重用原则。它将对项目成本、时间安排和工作产生明显的副面影响。
耦合：DAO代码与JDBC接口和核心collection耦合得非常紧密。从每个DAO类的导入声明的数量可以明显地看出这种耦合。
资源耗损：依据EmployeeDAOImpl类的设计，所有DAO方法必须释放对所获得的连接、声明、结果集等数据库资源的控制。这是危险的主张，因为一个编程新手可能很轻易漏掉那些约束。结果造成资源耗尽，导致系统停机。
错误处理：JDBC驱动程序通过抛出SQLException来报告所有的错误情况。SQLException是检查到的异常，所以开发人员被迫去处理它，即使不可能从这类导致代码混乱的大多数异常中恢复过来。而且，从SQLException对象获得的错误代码和消息特定于数据库厂商，所以不可能写出可移植的DAO错误发送代码。
脆弱的代码：在基于JDBC的DAO中，两个常用的任务是设置声明对象的绑定变量和使用结果集检索数据。假如SQL where子句中的列数目或者位置更改了，就不得不对代码执行更改、测试、重新部署这个严格的循环过程。
让我们看看如何能够减少这些问题并保留DAO的大多数优点。
进入Spring DAO
先识别代码中发生变化的部分，然后将这一部分代码分离出来或者封装起来，就能解决以上所列出的问题。Spring的设计者们已经完全做到了这一点，他们发布了一个超级简洁、健壮的、高度可伸缩的JDBC框架。固定部分（像检索连接、预备声明对象、执行查询和释放数据库资源）已经被一次性地写好，所以该框架的一部分内容有助于消除在传统的基于JDBC的DAO中出现的缺点。
图2显示的是Spring JDBC框架的主要组成部分。业务服务对象通过适当的接口继续使用DAO实现类。JdbcDaoSupport是JDBC数据访问对象的超类。它与特定的数据源相关联。Spring Inversion of Control （IOC）容器或BeanFactory负责获得相应数据源的配置具体信息，并将其与JdbcDaoSupport相关联。这个类最重要的功能就是使子类可以使用JdbcTemplate对象。
图2. Spring JDBC框架的主要组件
JdbcTemplate是Spring JDBC框架中最重要的类。引用文献中的话：“它简化了JDBC的使用，有助于避免常见的错误。它执行核心JDBC工作流，保留应用代码以提供SQL和提取结果。”这个类通过执行下面的样板任务来帮助分离JDBC DAO代码的静态部分：
从数据源检索连接。
预备合适的声明对象。
执行SQL CRUD操作。
遍历结果集，然后将结果填入标准的collection对象。
处理SQLException异常并将其转换成更加特定于错误的异常层次结构。
利用Spring DAO重新编写
既然已基本理解了Spring JDBC框架，现在要重新编写已有的代码。下面将逐步讲述如何解决前几节中提到的问题。
第一步：修改DAO实现类- 现在从JdbcDaoSupport扩展出EmployeeDAOImpl以获得JdbcTemplate.
import org.springframework.jdbc.core.support.JdbcDaoSupport;
import org.springframework.jdbc.core.JdbcTemplate;
public class EmployeeDAOImpl extends JdbcDaoSupport
implements IEmployeeDAO{
public List findBySalaryRange(Map salaryMap){
Double dblParams [] = {Double.valueOf((String)
salaryMap.get("MIN_SALARY"))
,Double.valueOf((String)
salaryMap.get("MAX_SALARY"))
};
//The getJdbcTemplate method of JdbcDaoSupport returns an
//instance of JdbcTemplate initialized with a datasource by the
//Spring Bean Factory
JdbcTemplate daoTmplt = this.getJdbcTemplate();
return daoTmplt.queryForList(FIND_BY_SAL_RNG,dblParams);
}
}
在上面的清单中，传入参数映射中的值存储在双字节数组中，顺序与SQL字符串中的位置参数相同。queryForList（）方法以包含Map（用列名作为键，一项对应一列）的List（一项对应一行）的方式返回查询结果。稍后我会说明如何返回传输对象列表。
从简化的代码可以明显看出，JdbcTemplate鼓励重用，这大大削减了DAO实现中的代码。JDBC和collection包之间的紧密耦合已经消除。由于JdbcTemplate方法可确保在使用数据库资源后将其按正确的次序释放，所以JDBC的资源耗损不再是一个问题。
另外，使用Spring DAO时，不必处理异常。JdbcTemplate类会处理SQLException，并根据SQL错误代码或错误状态将其转换成特定于Spring异常的层次结构。例如，试图向主键列插入重复值时，将引发DataIntegrityViolationException.然而，假如无法从这一错误中恢复，就无需处理该异常。因为Spring DAO的根异常类DataAccessException是运行时异常类，所以可以这样做。值得注重的是Spring DAO异常独立于数据访问实现。假如实现是由O/R映射解决方案提供，就会抛出同样的异常。
第二步：修改业务服务- 现在业务服务实现了一个新方法setDao（），Spring容器使用该方法传递DAO实现类的引用。该过程称为“设置方法注入（setter injection）”，通过第三步中的配置文件告知Spring容器该过程。注重，不再需要使用DAOFactory，因为Spring BeanFactory提供了这项功能：
public class EmployeeBusinessServiceImpl
implements IEmployeeBusinessService {
IEmployeeDAO empDAO;
public List getEmployeesWithinSalaryRange(Map salaryMap){
List empList = empDAO.findBySalaryRange(salaryMap);
return empList;
}
public void setDao(IEmployeeDAO empDAO){
this.empDAO = empDAO;
}
}
请注重P2I的灵活性；即使极大地改动DAO实现，业务服务实现也只需少量更改。这是由于业务服务现在由Spring容器进行治理。
第三步：配置Bean Factory- Spring bean factory需要一个配置文件进行初始化并启动Spring框架。这个配置文件包含所有业务服务和带Spring bean容器的DAO实现类。除此之外，它还包含用于初始化数据源和JdbcDaoSupport的信息：
？XML version="1.0" encoding="UTF-8"？
!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd"
beans
!-- Configure Datasource --
bean id="FIREBIRD_DATASOURCE"
class="org.springframework.jndi.JndiObjectFactoryBean"
property name="jndiEnvironment"
props
prop key="java.naming.factory.initial"
weblogic.jndi.WLInitialContextFactory
/prop
prop key="java.naming.provider.url"
t3://localhost:7001
/prop
/props
/property
property name="jndiName"
value
jdbc/DBPool
/value
/property
/bean
!-- Configure DAO --
bean id="EMP_DAO" class="com.bea.dev2dev.dao.EmployeeDAOImpl"
property name="dataSource"
ref bean="FIREBIRD_DATASOURCE"/ref
/property
/bean
!-- Configure Business Service --
bean id="EMP_BUSINESS"
class="com.bea.dev2dev.sampleapp.business.EmployeeBusinessServiceImpl"
property name="dao"
ref bean="EMP_DAO"/ref
/property
/bean
/beans
这个Spring bean容器通过调用JdbcDaoSupport提供的setDataSource（）方法，设置包含DAO实现的数据源对象。
第四步：测试- 最后是编写JUnit测试类。依照Spring的方式，需要在容器外部进行测试。然而，从第三步中的配置文件可以清楚地看到，我们一直在使用WebLogic Server连接池。
package com.bea.dev2dev.business;
import java.util.*;
import junit.framework.*;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;
public class EmployeeBusinessServiceImplTest extends TestCase {
private IEmployeeBusinessService empBusiness;
private Map salaryMap;
List eXPResult;
protected void setUp() throws Exception {
initSpringFramework();
initSalaryMap();
initExpectedResult();
}
private void initExpectedResult() {
expResult = new ArrayList();
Map tempMap = new HashMap();
tempMap.put("EMP_NO",new Integer(1));
tempMap.put("EMP_NAME","John");
tempMap.put("SALARY",new Double(46.11));
expResult.add(tempMap);
}
private void initSalaryMap() {
salaryMap = new HashMap();
salaryMap.put("MIN_SALARY","1");
salaryMap.put("MAX_SALARY","50");
}
private void initSpringFramework() {
ApplicationContext ac = new FileSystemXmlApplicationContext
("C:/SpringConfig/Spring-Config.xml");
empBusiness =
(IEmployeeBusinessService)ac.getBean("EMP_BUSINESS");
}
protected void tearDown() throws Exception {
}
/**
* Test of getEmployeesWithinSalaryRange method,
* of class
* com.bea.dev2dev.business.EmployeeBusinessServiceImpl.
*/
public void testGetEmployeesWithinSalaryRange() {
List result = empBusiness.getEmployeesWithinSalaryRange
(salaryMap);
assertEquals(expResult, result);
}
}
使用绑定变量
到目前为止，我们搜索了工资介于最低值和最高值之间的雇员。假设在某种情形下，业务用户想要颠倒这一范围。DAO代码很脆弱，将不得不通过更改来满足要求的变化。这个问题在于使用了静态的位置绑定变量（用“？”表示）。Spring DAO通过支持命名的绑定变量来拯救这个情况。修改的IEmployeeDAO清单引入了命名的绑定变量（用“：some name”表示）。注重查询中的变化，如下所示：
import java.util.Map;
public interface IEmployeeDAO {
//SQL String that will be executed
public String FIND_BY_SAL_RNG = "SELECT EMP_NO, EMP_NAME, "
+ "SALARY FROM EMP WHERE SALARY = :max AND SALARY = :min";
//Returns the list of employees falling into the given salary range
//The input parameter is the immutable map object obtained from
//the HttpServletRequest. This is an early refactoring based on
//- "Introduce Parameter Object"
public List findBySalaryRange(Map salaryMap);
}
多数JDBC驱动程序仅支持位置绑定变量。所以，Spring DAO在运行时将这个查询转换成位置绑定、基于变量的查询，并且设置正确的绑定变量。现在，为了完成这些任务，需要使用NamedParameterJdbcDaoSupport类和NamedParameterJdbcTemplate类，以代替JdbcDaoSupport和JdbcTemplate.下面就是修改后的DAO实现类：
import org.springframework.jdbc.core.namedparam.NamedParameterJdbcDaoSupport;
import org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate;
public class EmployeeDAOImpl extends NamedParameterJdbcDaoSupport
implements IEmployeeDAO{
public List findBySalaryRange(Map salaryMap){
NamedParameterJdbcTemplate tmplt =
this.getNamedParameterJdbcTemplate();
return tmplt.queryForList(IEmployeeDAO.FIND_BY_SAL_RNG
,salaryMap);
}
}
NamedParameterJdbcDaoSupport的getNamedParameterJdbcTemplate（）方法返回一个NamedParameterJdbcTemplate实例，该实例由数据源句柄进行了预初始化。Spring Beanfactory执行初始化任务，从配置文件获得所有的具体信息。在执行时，一旦将命名的参数替换成位置占位符，NamedParameterJdbcTemplate就将操作委托给JdbcTemplate.可见，使用命名的参数使得DAO方法不受底层SQL声明任何更改的影响。
最后，假如数据库不支持自动类型转换，需要如下所示，对JUnit测试类中的initSalaryMap（）方法稍做修改。
private void initSalaryMap() {
salaryMap = new HashMap();
salaryMap.put("MIN_SALARY",new Double(1));
salaryMap.put("MAX_SALARY",new Double(50));
}
Spring DAO回调函数
至此，已经说明为了解决传统DAO设计中存在的问题，如何封装和概括JdbcTemplate类中JDBC代码的静态部分。现在了解一下有关变量的问题，如设置绑定变量、结果集遍历等。虽然Spring DAO已经拥有这些问题的一般化解决方案，但在某些基于SQL的情况下，可能仍需要设置绑定变量。
在尝试向Spring DAO转换的过程中，介绍了由于业务服务及其客户机之间的约定遭到破坏而导致的隐蔽运行时错误。这个错误的
