SPRING数据访问对象(DAO)框架入门

　　上面的清单说明了DAO方法的一些要点：

　　它们封装了所有与JDBC API的交互。如果使用像Kodo或者Hibernate的O/R映射方案，则DAO类可以将这些产品的私有API打包。

　　它们将检索到的数据打包到一个与JDBC API无关的传输对象中，然后将其返回给业务层作进一步处理。

　　它们实质上是无状态的。唯一的目的是访问并更改业务对象的持久数据。

　　在这个过程中，它们像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;

上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] 下一页

复制本页网址和标题，发送给你QQ/Msn的好友一起分享

上一篇:实战角度比较EJB2和EJB3的异同

下一篇:实战角度比较EJB2和EJB3的架构异同