讨论：在DAO中对Hibernate的封装

什么是AOP，IOC？
不懂，新手一个，认真学习中 。。。

哎，讨论了这么长时间，也没有人牵个头把总结一下Dao封装hibernate的一个合理的可行的方案并整理出代码大家分享一下啊。对那些已经很熟悉hibernate的朋友来说，这个该不是很难的事情吧。讨论技术上的问题是正确的，但是如果有相关的代码作为辅助说明的话，大家理解起来才不会吃力吧？！不知大家怎么认为？

无人发表意见那:)

其实，为什么要做DAO?无非是：
1， 管理connection/transaction (hibernate的话就是session/transaction)
2, 便于进行统计/log操作；
3， 便于进行权限控制；

DAO模式中，有两类对象，一种是DAO，一种是valueObject。 在我们讨论的这个情况中，value object是hibernate对应的POJO.

那么，按照我的理解，DAO就是一个Transaction包装器，其逻辑结构就是商业的具体事务。此处，数据库的transaction和商业的事务是统一的。

这里有一篇不错的关于DAO的文章。

http://www-106.ibm.com/developerworks/java/library/j-dao/

不太懂你的意思，能不能具体解释一下？

为什么非要在业务层获得Session，然后做为参数传递给DAO呢？这是个设计错误！DAO接口实现类代码自己去创建Session，用完就关掉就行了。遇到lazy loading的时候initial一下就可以了。Session的整个生命周期都在DAO内部进行，又怎么会跑到业务层和Web层去呢？

Session根本就不需要进行缓冲，SessionFactory创建Session的时间开销就是一个对内存的WeakHashMap的一次操作而已，时间开销少到可以忽略不计，如果对它都要进行池缓冲的话，反而把一个简单的操作步骤搞的异常复杂，进行对池的多步操作和状态管理才能拿到一个Session，这不是画蛇添足吗！会降低获得Session的操作的效率，得不偿失！

其实Hibernate是一个非常新的技术，甚至在美国和欧洲都鲜有人知道，所以不要觉得拿到一个老外写的代码就觉得他的设计思路就是对的，然后就进行模仿。他并不比你知道到的更多，甚至他根本就是错的。在Hibernate应用方面，我们中国算是走在前面的了。

总之按照自己的思路，大胆的设计，小心的求证，多点自信，勇敢的置疑权威。

我也觉得没必要再封装DAO了,我会在SessionBean里面直接调用Hibernate,hibernate已经可以支持多种数据库.当然一些复杂的查询或者数据库操作还是会用一下DAO.

就好像我会在session bean里面调用CMP一样,难道我还会用DAO先封装CMP?

技术总是要向前发展的。如果你现在不用DAO的话，那么以后当你想改版升级，使用新版本的Hibernate的时候就困难了。

比如说吧，一年前写的程序，当时用的是Hibernate 1.2，如果你现在出于功能上的要求，希望替换为Hibernate2.1，你就必须修改业务层代码，大面积修改。

如果当时你用了DAO，那么修改就局限在DAO实现类中。

Session的创建和关闭其实就是内存对象操作，非常轻量级，一般情况下不需要考虑那么多，在DAO里面操作就可以了。除非碰到那种一次用户的交互中非常频繁的DAO方法调用，才会考虑到要在DAO外面创建Session。不过即便如此，也并不能够提高数据库操作效率，因为就算用ThreadLocal来保证一次用户交互只有一次Session的创建关闭操作，但是每次通过 Thread.currentThread()获得当前Thread，然后去查一个WeakHashMap获得ThreadLocal变量这样的时间开销和创建关闭Session的时间开销是差不多的，唯一的区别是Session操作涉及到HashMap的修改，是线程同步方法，太过频繁的修改操作会产生瓶颈。

我不太清楚你说的批量化创建的意思，如果这种情况，可以考虑单独写一个DAO方法来实现吧



为什么不能输入对象呢？没有看明白...