JDBC是一种DAO，ORM也是一种DAO。关键看DAO怎么定义了。
to guty:
我理解hibernate与jdbc是同一层次的东西。
"使用hibernate后就不需要DAO"
I don't think so.用不用hibernate与用不用DAO没有必然联系。这其实涉及到对DAO的作用的理解。DAO的一个重要目的是为了将"操作"/"属性"分开。
回头再看你所提出的结构:session bean ->POJO
在这个结构中,POJO的功能是"操作"+"属性"；
如果我们愿意让"操作"+"属性"不分开，自然也可以不用DAO，如下:
session bean ->java object
其中java object是(数据库操作+value object)。
但我们都不愿意这么做，而是将java object分割为DAO+value object
--请指教
to robbin:
>澄清一个事实：Hibernate本身没有事务处理功能！
I think so.使用container的transaction，在transaction context中调用hibernate就OK。当然hibernate中所使用的connection从txDatasource中获取
> 不知我的理解是否正确。
> 你的意思是不是，如果在同一个数据库连接里面处理的话，通
> 柚JDBC transaction 隔离级别为Serializable mode？
> 如果是跨多个数据库的话，所有的数据库设置为最高隔离级别
> 庋拍鼙Ｖづupdate/delete完整性和一致性.
>
你误解了。我的意思很简单，如果在一个数据库连接中，既用Hibernate修改数据库，又用JDBC直接修改数据库，当然要考虑POJO同步的问题。如果分别在不同的数据库连接中各自干各的，本来互不干扰，就根本没有必要去管数据同步问题。
Hibernate有一个很方便的功能, 它把持久层对象中的表数据定义从代码中分离出来, 防在配置文件中, 这比传统ORM使用code generator的方法要自动高效. 在struts中action mapping也采用了类似的方法, 这些简洁实用的设计在好的架构中应用的很普遍.
good
我认为DAO的真正意义在于隔离会话，隔离事务，把这些封装到DAO里面才是真正的数据访问对象，
不论是DAO+Jdbc或 者是DAO+Hibernate其实思想都一样，但是事务这一块需要“横切”出来在BO里面
不直接调用连接jdbc connection 或hibernate session 通过事务封装类来间接调用地层所有dao
合理组合搭配到事务中去，DAO+ hibernate 我还有个很深刻的感受，很多人对PO和VO做了太多的争论
认为PO不能做VO, VO也不能做PO，诚然这点没有什么错误，有的人甚至想出了很极端的方法
利用BeanUitl.copyproperties(destVO, srcPO)的方法来转换，我认为效率太低。
DAO在这其中又是一个非常重要的角色了，DAO分离了连接会话，它也分离了PO和VO非常的微妙。
DAO传入的参数可以是VO得到的结果也是VO，DAO外界不跟任何PO打交道，只有DAO内布才存在PO
这样开发起来是很轻松的，不过这样会出先session的频繁打开和关闭，幸好hibernate 在这方面做了
大量的工作用线程池来负责维护会话，我想我们不必过多担心这个问题，我现在做了大量的封装
DAO隔离会话，隔离PO VO 同时配合抽象通用事务类完成复杂的事务控制。我感觉这样的DAO才是真正意义
上的DAO，这些全部继承我过去对DAO + jdbc orm的封装思想，采用抽象工厂和接口多态继承和实现
xxxDAOImplOracle xxxDAOImpleSqlsrv ...的机制可以跨任何的数据库
现在DAO + hibernate 也完好继承了过去的思想，而且用起来更强大，更方便。
我认为DAO的真正意义在于隔离会话，隔离事务，把这些封装到DAO里面才是真正的数据访问对象，
不论是DAO+Jdbc或 者是DAO+Hibernate其实思想都一样，但是事务这一块需要“横切”出来在BO里面
不直接调用连接jdbc connection 或hibernate session 通过事务封装类来间接调用地层所有dao
合理组合搭配到事务中去，DAO+ hibernate 我还有个很深刻的感受，很多人对PO和VO做了太多的争论
认为PO不能做VO, VO也不能做PO，诚然这点没有什么错误，有的人甚至想出了很极端的方法
利用BeanUitl.copyproperties(destVO, srcPO)的方法来转换，我认为效率太低。
DAO在这其中又是一个非常重要的角色了，DAO分离了连接会话，它也分离了PO和VO非常的微妙。
DAO传入的参数可以是VO得到的结果也是VO，DAO外界不跟任何PO打交道，只有DAO内布才存在PO
这样开发起来是很轻松的，不过这样会出先session的频繁打开和关闭，幸好hibernate 在这方面做了
大量的工作用线程池来负责维护会话，我想我们不必过多担心这个问题，我现在做了大量的封装
DAO隔离会话，隔离PO VO 同时配合抽象通用事务类完成复杂的事务控制。我感觉这样的DAO才是真正意义
上的DAO，这些全部继承我过去对DAO + jdbc orm的封装思想，采用抽象工厂和接口多态继承和实现
xxxDAOImplOracle xxxDAOImpleSqlsrv ...的机制可以跨任何的数据库
现在DAO + hibernate 也完好继承了过去的思想，而且用起来更强大，更方便。
这个话题非常好哦，我也来说说几句，哈哈。只是使用Java 事务讨论讨论作为标题不是很确切。
怎么说呢，大家都从不同的经验来讨论各自不同方面的认识。就我的经验而言，我和tonykee比较类似。在hibernate出现之前，我就使用了DAO模式来隔离对数据的访问，而模仿我的EJB做法，在DAO的参数中基本是VO或VO列表，有关联的话，使用复合模式，在DAO里的resultSet映射到VO(赋值),当然处理不好很容易出现复合Vo的时候我们常说的n+1次数据查询交互的缺点，但是可以完全避免的。基本上完成了O/R mapping的思想。在业务逻辑端操作的是vo或vo列表。然后其实我又参考了我使用EJB中的经验，写了一个DAOManager类来管理所有的DAO调用，实现了Facade模式，和Session Facade类似，^_^。
Hibernate是一个不错的东西，Hibernate出来后我也看大家对他很热眼，我也跟着看看，但只看了它的一些外围的东西，也觉得没有什么啦，看了它的配置的xml，有sqlTyp呀javaType呀Bean Class 属性呀是否为null呀等等，哈哈和我的代码生成器生产的数据库Info.xml很象，还有vo和dao全都生成了。然后我就想了它怎么从resultSet到Bean 属性的映射的呢，因为我的dao实现的时候我就想了是用反射还是直接resultSet调用getX方法，最后我采用了getX方法，反正都是生成的，虽然dao里面的代码量很大，因为反射大量查询的时候性能太差了，但我看了hibernate后我第一个想法就是它用反射来处理，因为它的配置xml文件太明显了，这样的话，笑批量查询的时候应该问题还可以忍受，但批量就不行了。
后来我发现了它的依赖包中有cglib.jar，然后我估计它是用这个来代替反射了，性能应该上去了 ，但还是绝对不能跟直接vo.SetX(rs.getX)比的。
我还是放弃掉hibernate，当然跟重要的原因是要有生成器，负责开发效率很低的，因为实现去学那些jdbc的工作量超大，容易“手误”等。
说真的如果你对xdoclet也很了解,在vo中就可以生成出它对hibernate的tag.呵呵,我是这样的还有tjdo(xdolclet也支持生成),包括EJB等生成一个bean类,然后ant xdoclet全出来了.呵呵.其实如果你对jdbc了解了 ,对o/r
mapping的概念了解了,最好你有自己的工具,呵呵,爱怎么样都行,无非就是
性能,稳定性,很重要要的是OO哦,这就是o/r mapping存在的必要.
关键是思想(想提醒一下初学的同行们,虽然我一直认为自己不是最厉害的那些人),这个很总要,软件思想很总要,所以Banq的设计模式的传道我觉得很有意义.呵呵,就象有些人说懂了模式不还是技工,但你不懂模式可能将来技工都当不好哦,反正懂比不懂好,题外话。