我在现在的项目中在DAO层中对Hiberante做了如下封装:
代码
在具体的DAO中,用有个DAO接口来定义方法(如AccountDAO),
代码
在业务逻辑层中通过DAO工厂来取这些DAO并执行之,这里有几个问题不是很确信: 2:昨天才想到,其实对对象的CRUD来说,CUD方法非常的类似,
代码
但还没做更进一步的研究和试验,不知道是否可以实现,如果可以的话,把这三个方法再往上一抽,剩下的DAO实现中就只要完成一些查询等就够了,HOHO,哪岂不很爽》?呵呵:)回头试试去:) 嗯,还有很多问题,大家一起来讨论下:) |
讨论:在DAO中对Hibernate的封装
最新推荐文章于 2024-07-17 14:39:25 发布
一个简单的设计,UML图标不是很标准,DAO的一些方法也都没有写出来。还有返回值什么的都没有斟酌
强烈支持!这样对新手很有帮助d!
Spring对Hibernate进行了封装,
其中的
还有:
看名字就能猜出它们的作用了。
DAO中的代码大概是这个样子:
Service中的代码大概是这个样子:
什么连接、关闭、提交、回滚。。。统统地不要写了,在xml中说明一下就行了。
对于Spring+Hibernate,我也是初学乍练。有同道中人吗?切磋一下。
btw:
1、在这里提及Spring,不知坛主是否有意见?
2、论坛的时钟好像快了10多分钟,按照这个时间下班。。。
面向对象应该根据业务逻辑来封装对象,而不是按照使用的API来封装,我的面向对象的设计思路都写在 《面向对象的思维方法》
http://hibernate.fankai.com/viewtopic.php?t=38
里面。我考虑封装的出发点和你不太一样的。
可以用ThreadLocal 来管理Session,论坛有这方面的几个帖子,你用论坛搜索功能搜一下。
我没看过hibernate源码,但感觉hibernate已经封装了domain store,完成了底层dao的持久化,所以完全可以把映射类直接参与业务逻辑transparently,而不必再次把hibernate类封装在dao模式中,当然会有诸如session.update()等难以避免的操作。我才接触hibernate,望多多指教。
哇,这么都回复了啊;)
上半年被项目整死,现在有点空了,好好看看先:)
现在我更倾向于使用Spring来处理业务,见我的blog:
http://www.skyinn.org/wiki/Wiki.jsp?page=Java_blogentry_270704_1
目前还在学习Spring中,故而很多东西还不知道
现在回过头来看看当初自己的这个设计,确实存在太多的弊端,
在我们的项目中,最大的问题不是哪里去获得session等,而是事务的处理,
对于业务层,他并不知道后台persistence层到底是hibernate还是纯jdbc,因为都是面向接口的,透明处理了,然而当需要处理事务的时候就出现麻烦了,
因为如果将session放在业务层,那么势必增加业务层和持久层间的耦合(至少得传session)。。。
而现在我们的做法是使用spring来管理事务等,见上面我的回复,
唉,如果当初就了解点spring的话。。。。。
是应该去用Spring,很方便也很透明,对Hibernate的支持也没话说
不过你以前的思路还是给了我很多启发,我也遇到过这个问题,就是事务的判断,如果自己写是需要一些技巧和方法
我的写的代码是
现在跑起来是没问题的,主要的疑问在于static方面的使用,我在这方面总有些缺乏经验
担心Session和Transaction是非线程安全,如果多线程读写会出现很大的问题,也在考虑是否把对数据的操作都做成静态方法,不知道好不好
简单的来说,如果你用EJB,那么用容器管理事务;如果不用EJB,那么用ThreadLocal来管理Session和Transaction。Transaction的提交和Session的关闭在ServletFilter里面完成。如果需要在一次用户请求过程中,完成n次Transaction的话(实际上很少发生这样的需求),就在DAOImpl里面提交Transaction。
总之,不管用不用EJB,你所有的Hibernate的代码都是封装在DAOImpl里面的,业务层不需要也不应该出现Hibernate的代码。
这里有误导,即使使用ejb如果事务没有移交到ejb容器的话,也是一定要做threadlocal的,注意以下选择根据需求发生变化,如果并发很大,没有写入问题
光是查询的话也可以不做threadlocal,反之用threadlocal来管理session试必不可少的
为啥不用Spring+Hibernate 那?
只要在DAO操作如下就可以了:
因为Spring已经支持了Hibernate的DAO操作,把事务都封装在了配置文件中: