讨论：在DAO中对Hibernate的封装

看看spring framework对hibernate的DAO封装吧, 会有帮助的

http://www.hibernate.org/110.html

3.对 Transaction 的处理
  不在 DAO 层处理 Transaction
  如果确实需要 Transaction ，在上一层，比如业务层里的 Session Bean 里来做。



把事务全放到业务层，也不是很好吧！
我觉的应该灵活控制的，比如一个在dao 下面的一个原子操作，我应该可以控制，我告诉它是在一个事务里的，它就自动提交，它不在一个事务里，就有外部的业务bean 来控制事务。

应该是这样吧

我个人认为肯定需要有对事物的控制权，无论是declare式的还是programic式的，原因很简单架设一个仓库系统需要入库处理那么在一个入库的业务bean中至少要调用在库和出库两张表的操作，也就是在库和出库俩个po(其实还要多)并且都要作update和insert的操作，所以对俩个po的操作要进行事务管理，而且也只有业务对象知道事务的边界（何时开始，何时结束）。另外把session放在localthread里面也不可取，因为对大型web运用来说事务是绝对不能跨request的，甚至不能超出一个业务服务，所以一般在在一个service中肯定可以控制事务了，所以我认为业务对象之下的ado包括两个独立的模块一个是事务管理器，一个是curs操作，而后者完全不对事物进行管理！

KAVIN KING 说过不应当在METHOD LEVEL 来 OPEN 和 CLOSE SESSION。这一点应该是肯定的。
不过在DAO 中处理事务(TRANSACTION)时，如何处理SESSION不太明白。

可是在Hibernate的两个presentation里面，都很明确的说dto是evil，just enhance error prone ahd loc。好像和robbin说的有点出入。
（formbean的来回转化，而且ww在vs struts的时候，也把取消了formbean作为自己的pros在吹）

robbin能不能就这个问题再解释一下？谢谢！

事务(TRANSACTION) 到底应该在那里实现呢？是在业务层还是在DAO中实现？
用过事务的大侠能否谈谈经验？谢谢。

我比较倾向于bbbb的说法，就是根据需要来选择将事务控制放在业务层，还是放在数据访问层，如果该操作涉及几个表的操作，那么就需要将事务的控制放在业务层，如果只是单表操作那么完全可以由数据访问层自己来控制事务

cinc朋友说在业务层处理事务，我比较同意，但如果在业务层处理事务那必须要在业务层使用session，那么这个session就要做为参数传给CRUD方法，
这样就破坏了DAO对session的封装性，请问这不是很矛盾么，请robbin给出一个解决方案

我很早以前就说过n次的话题了。搜索一下最早的帖子。

简单的来说，如果你用EJB，那么用容器管理事务；如果不用EJB，那么用ThreadLocal来管理Session和Transaction。Transaction的提交和Session的关闭在ServletFilter里面完成。如果需要在一次用户请求过程中，完成n次Transaction的话(实际上很少发生这样的需求)，就在DAOImpl里面提交Transaction。

总之，不管用不用EJB，你所有的Hibernate的代码都是封装在DAOImpl里面的，业务层不需要也不应该出现Hibernate的代码。

我觉得应该做一个集中管理类来把所有的hibernate代码访到一起。它主要维护对象间的关系。这样代码要方便多了。
   业务层对象直接调用它就可以了。