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

上面的清单说明了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框架的主要组件

共5页: 上一页 [1] 2 [3] [4] [5] 下一页

【文章评论】 【收藏本文】 【推荐好友】 【打印本文】 【论坛讨论】

相关文章:

·Java文件操作大全(1) ·JAVA开发者应该去的20个英文网站 ·Java: JNI完全手册 ·由基本概念开始全面认识Java ·J2ee学习流程简介 ·Java：Struts入门初步知识(1)

文章评论:(0条)

请留名： 匿名评论   点击查看所有评论 网管论坛

责任编辑:it167  声明：刊登此文章是为了传递更多信息,文章内容仅供参考,转载请注明出处。