DAO应用方案

引言
大家都是张口闭口DAO，可是谁也没有给出一个完整的方案，让我们这些没有DAO过的人感觉真的无从下手，我仔细看了DAO模式的文档，大概总结了一下DAO应用的相关问题，请大家多提宝贵意见。

前提
SessionBean + DAO + Hibernate
系统按模块分多个小组开发

关于DAO模式
DAO=Data Access Object
DAO是对数据访问逻辑的封装，使SessionBean的业务逻辑实现更加清晰，另外，结合抽象工厂模式可以解耦业务逻辑和数据访问逻辑，在Hibernate这一层发生变化的时候（比如API变化，或者干脆换JDO），只修改DAO层的实现，而不必修改SessionBean的业务逻辑代码。DAO模式的详细描述参见http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

设计
DAO工厂类：每个模块设计一个抽象DAO工厂类（这样做主要是为了便于分组开发），命名为ModulenameDAOFactory.java，例如SaleDAOFactory，还要有一个HibernateDAO工厂实现类继承上面的抽象类，命名为ModulenameH2DAOFactory.java，其中H2代表Hibernate 2.0，以后可能会有ModulenameH3DAOFactory.java, ModulenameJDODAOFactory.java什么的
DAO类：基本上以每个实体类对应一组DAO接口和实现类的原则，例如已有实体类User.java，就要设计一个接口UserDAO.java，里面定义必要的数据存取方法，再设计一个UserH2DAO.java，实现UserDAO.java。当然应用这个原则有一个大的前提就是首先要符合业务逻辑实现的需要，不一定每个实体类设计一组DAO类。DAO在操作数据之前先获取Hibernate的Session对象，方法返回前关闭Session。

包路径

com
  company
    product
      module1---------------->模块名
        dao------------------>DAO类，DAO工厂类
        entity--------------->实体类
        session-------------->Stateless SessionBean
      module2
      module3...

最后还有一个关于DAO模式的疑问，就是我们选择Hibernate的一个重要的原因是终于可以直接拿POJO作实体对象，使MIS系统更面向对象，而加了DAO层以后，实体的行为好像表现不出来了，实体类的作用又回到了仅仅映射持久层的作用，而不是有属性有方法的对象，实体类无法在自己的方法里操作其它实体类。要下班了，回家以后写个例子。

这就是使用dao的目的。如果没有这个目的，就不要使用dao了，纯粹增加麻烦。

对于使用o/r mapping来说，dao不是一个很好的选择，反之亦然。原因，就如你说的，dao是分离业务模型和存储实现，而o/r mapping是尽可能的运用业务对象直接完成存储。两者目的不同，甚至有些矛盾。这时候，就要看你的设计目的了。
对于应对将来存储实现的可能变化，那么dao是一定要的，同时选中hibernate，存在两种形式，一种，专门建立hibernateVo,另一种就是还利用原有对象。建议采用第一种，因为第二种，意味者你的对象设计可能会根据hibernate的特性做一些调整，当变换存储实现时，带来不可预见的麻烦，而第一种虽然麻烦一些，但是可以真正满足业务和存储的分离。
但是，这就意味着你的所有相关设计也必须为：将来存储层的可能变化，而努力。
个人建议：对于项目，我尽量不使用dao，直接利用o/r mapping的优势。对于产品，尽量使用dao，存储层的化，hibernate只是其中一个选择。

看来不用写例子就已经很清楚了。同意youcai的观点！

我十分同意youcai的觀點,如果用o/r mapping,無必要再用DAO.