浅谈DAO工厂设计模式

随着软件分层设计的流行及广泛的应用，对于DAO的设计模式大家已经不再陌生了，DAO层已经在软件系统的开发中成为必不可少的一层，将后台的数据层和前台的VO进行分离。前段时间也针对于DAO的设计介绍过一个基于Hibernate的泛型DAO的设计。
csdn blog：http://blog.csdn.net/yongtree/archive/2008/03/12/2172071.aspx
javaeye blog：http://yongtree.iteye.com/blog/170449

      通过DAO的设计的确可以让我们的软件系统已经将数据层和表现层进行了简单的分离，让我们系统各层次的功能更加的清晰。所以我们开始洋洋得意了，DAO的引入让系统的耦合性更加的松散，表现层再也不需要关心后台数据操作的变化了。于是我们开始高枕无忧了，我们肆无忌惮的在表现层通过调用DAO来实现我们的系统了。事实真的如此吗？那我们就举个例子来看看我们的系统是否真的具有解偶的能力了。
      现在我们有个员工管理系统，在该系统中，Person.java表示员工这个对象，它对应着数据库中的person表。还有用于操作Person对象的DAO接口—PersonDAO.java，还有一个PersonDAO的实现类PersonDAOImpl.java。在PersonDAOImpl.java中我们实现了操作Person对象的所有的方法。我们很自豪的说，看我们已经把操作封装在PersonDAO中了，现在我们可以在表现层（jsp，或者VO操作类中）使用PersonDAO personDAO=new PersonDAOImpl()来调用DAO操作我们的数据对象了。当我们陶醉于自己写的优美的代码的时候，项目经理来通知了，由于使用Hibernate的效率偏低，客户开始不满了，还是让我们重新用JDBC再重写一遍吧。于是所有DAO的Hibernate实现开始全部转换成JDBC实现。但是项目经理建议不要破坏现有的Hibernate实现，以后可以通过技术研究来提升Hibernate的访问效率。于是我们开始写了又写了一套JDBC的实现—PersonDAOJDBCImpl.java，现在问题出来了，表现层大量的使用了PersonDAO personDAO=new PersonDAOImpl()，全部改成new PersonDAOJDBCImpl()谈何容易，我们是不是开始欲哭无泪了。
      怎么解决类似的问题呢？于是我们开始引进工厂模式。我们建立一个类DaoFactory.java对DAO进行统一管理。
DaoFactory.java:
      public class DaoFactory{
      public static PersonDAO getPersonDAOInstance()
      {
           return new PersonDAOImpl() ;
      }
      //得到其他的DAO实例
      ……
}
表现层通过PersonDAO personDAO=DaoFactory.get getPersonDAOInstance();来实例化DAO实例。这样问题就解决了，DAO改变了，我们只需要在DAO工厂类中修改一下代码：return new PersonDAOJDBCImpl() ;那我们的应用就快速切换到JDBC实现了。可见利用工厂模式，我们的系统又进一步的解耦，表现层真的无需再关系DAO层的变化了，一切交给DAO工厂来解决。
使用过Spring这样框架的开发人员都知道，Spring通过利用IoC来实现类之间的解耦。其实在DAO工厂中我们也可以简单的借鉴一下IoC的思想，更进一步解除类之间的耦合。Spring是通过配置xml文件来进行IoC的，那么我们也可以借助于xml文件来实现。比如下面的xml：
<?xml version="1.0"?>
<config>
    <daos>
       <!-- 组织机构服务接口实现类 -->
       <dao id="organizationService"
           type="com.baiyyy.oa.services.organization.OrganizationServiceImpl">
       </dao>
       <!-- 工作流参与者接口 -->
       <dao id="participantService"
           type="com.baiyyy.workflow.services.impl.ParticipantServiceImpl">
       </dao>
       <!-- 工作流定义接口 -->
       <dao id="processDefinitionService"
           type="com.baiyyy.workflow.services.impl.ProcessDefinitionServiceImpl">
       </dao>
       <!-- 工作流实例接口 -->
       <dao id="processInstanceService"
           type="com.baiyyy.workflow.services.impl.ProcessInstanceServiceImpl">
       </dao>
    </daos>
</config>
这是我设计实现的工作流系统给业务系统提供的接口所配置的xml，所有的接口都配置在xml中，我们怎么使用呢？我只不过是把DAO工厂进行进一步的改进，通过ProcessInstanceService processInstanceService=DaoFactory.getDao(ProcessInstanceService.class,” processInstanceService”);从传入的参数我们可以看出，我们清楚的知道要调用的接口ProcessInstanceService，同时通过字符串” processInstanceService”，我们可以解析上面的配置文件，得到具体实现类的路径，通过反射得到该实现类的实例。具体的DAO工厂类的实现，朋友们有兴趣可以自己去实现，我就不详细介绍了。
      终于写完了，以上便是对DAO工厂一些浅显的理解。现在正在学习设计模式，以后会根据自己的所学所思，介绍自己对各个设计模式的理解，希望大家一块学习讨论。

yongtree  2008-4-14 晚

使用spring来管理hibernate，就不会有这种困扰了。 楼主写的不错。

如果将对象的生成，
    对象属性的改变，
    对象方法的调用
等等所有操作全部都替换成方法调用

那么从技术手段上也就可以通过动态改变方法的指针这种相对比较简单的方法达到很多目的，比如说AOP类似的功能。

因此从设计角度上说，我们以前需要语法分析/编译分析才能做到的某些事情，现在通过加强代码规范和模式应用，也能做另外一个角度做到，并且抽象程度更高。

这是我的一点想法。

没看懂楼主到底想表达什么.
是DAO好还是DAO不好?还是如何实现一个松耦合的DAO..

我理解楼主是在和大家分享学习设计模式的心得，工厂模式 可以很好的解耦，spring的IoC能更好的解耦

是不是可以把dao作成无状态的单例对象？

解释的比较形象，good