在DAO中对Hibernate进行封装(新)

偶然看见 l_walker于2003-9-15写的一篇关于在DAO中对Hibernate的封装的文章被置于精华。再回想起我去年在自己的项目开发中使用的一种封装方法，觉得完全是另外一种思路。所以拿出来和大家讨论，说不定运气好也会被置为精华.

请看封装后的调用代码：

[code:1]

/**
* 用于管理...的Oracle dao
* <p>Company:... </p>
* @author chenxu
* @version 1.0
*/
public class UserOracleDAO {

/**
* 增加一个User
* @param vo UserVO
*/
public void addUser(UserVO vo, boolean needTrans) throws
AppException {
DoHibernateProc_save dproc = new DoHibernateProc_save(new Object[] {
vo}, needTrans);
dproc.doProc();
}

/**
* 更新一个User
* @param vo UserVO
*/
public void updateUser(UserVO vo, boolean needTrans) throws
AppException {
DoHibernateProc_update dproc = new DoHibernateProc_update(new
Object[] {
vo}, needTrans);
dproc.doProc();
}

/**
* 删除一个User
* @param vo UserVO
*/
public void delUser(UserVO vo, boolean needTrans) throws
AppException {
DoHibernateProc_delete doproc = new DoHibernateProc_delete(new
Object[] {
vo}, needTrans);
doproc.doProc();
}

/**
* 获得所有User
* @return List
*/
public List getAllUser(boolean needTrans) throws AppException {
DoHibernateProc_getLists dproc =
new DoHibernateProc_getLists(
"from UserVO as t where (t.deleted is null or t.deleted!=true)", needTrans);
dproc.doProc();
return (List) dproc.getResult();
}

/**
* 根据id查询User
* @param name Long
* @return UserVO
*/
public UserVO getUserById(Long id, boolean needTrans) throws
AppException {
DoHibernateProc_getObject dproc = new DoHibernateProc_getObject(new
Object[] {UserVO.class, id}, needTrans);
dproc.doProc();
UserVO eType = (UserVO) dproc.getResult();
return eType;
}[/code:1]

在以上的 DAO 实现类的 对于hibernate的调用代码中没有包含任何的hibernate API的直接调用，同时也无需处理hibernate 相关的异常,有的只是对于我的5个封装类 的调用。分别是：
DoHibernateProc_save------封装hibernate保存操作的类
DoHibernateProc_update------封装hibernate的更新操作的类
DoHibernateProc_delete------封装hibernate的删除操作的类
DoHibernateProc_getLists------封装hibernate的hql查询操作的类
DoHibernateProc_getObject------封装hibernate的按id查询的操作方法的类
;
同时其调用方法也简介明了，囊括了大部分的hibernate操作。
这样就实现了DAO开发人员和具体的Hibernate的操作的分离，可以由专门的对
hibernate非常熟悉的人员来开发维护此部分hibernate操作的代码，业务模块DAO开发人员对此无需有任何了解. 避免了不同模块的开发人员在各自的DAO中分别修改hibernate代码造成的混乱.

两种封装思路的比较：
l_walker的思路是对公用的方法（hibernate的API）进行封装，而我的思路是对常用的crud操作进行封装，是面向业务逻辑的封装。

l_walker的封装的结果是在其DAO中还是需要进行 hiernate的基本操作的调用比如：打开事务，打开session，关闭session，关闭事务，同时需要捕获hierbnate的异常HibernateException.

而我的封装结果是，
1，只需要用统一的方式调用我的封装类；
2，dao开发者无需了解任何关于hibernate的知识；
3，调用我的封装类一般只需2·3行简单的代码，也不用捕获专有的异常
（此异常在封装类中已被进行有效的正确的处理）。代码量精简！奇少！！
4，因为修改造成的hibernate操作错误或不当的几率大大降低，因为是统一的代码,将被统一的修改;


最后，请敬仰已久的robbin提出指正！！不胜荣幸之至

你这样的方式不方便与spring结合。

你这样的dao代码根本不需要开发，代码生成器生成即可。

DAO的代码框架当然可以生成，但是我这里讨论的是Hibernate的封装！

再说，Dao中数据访问代码如此的简介，难道不比一般的写法“打开事务、打开session、关闭session、关闭事务、处理异常”舒服多了吗？
所以我觉得这种封装方式也是对hibernate一个很好的补充！ 我想做到的是让 “数据访问的api代码、等等繁琐的数据访问细节”真正的和业务开发人员脱离。这也正是分层、封装的目的，不是吗？

代码风格看起来不爽 - DoHibernateProc_save , 没心思看下去

不知道怎么处理事务.还有不知道怎么获取hibernateSession

我在前面已经说过了，事务处理和
session的打开都在我的封装类中进行。
调用者（也就是DAO的开发人员不用关心），
也就是在DoHibernateProc_save 等类中。
当你调用doProc方法的时候封装类就会去执行事务、session的处理；
另外，Feiing 说的代码命名风格的问题和我这里讨论的关于封装方式的主题的关系并不大。

DAO也就那么些东西，spring封一层都已经差不多了，03年那会，大家还是直接用hibernate，spring刚出道，有必要封一下，现在还是直接用spring的hibernate封装省事，反正复杂一点的东西，还是得自己拿session出来用

我也不喜欢这种方法,不够灵活

请问, 您这个与 HibernateTemplate 相比有什么优势?