由于本人能力有限,加上来不及校对, 难免有些地方出现错误或者表达得不是特别准确,欢迎批评指正.
这是一个来自CaveatEmptor实例应用,在JDK5.0下实现的DAO模式. 这个模式在Java Persistence With Hibernate里面也有讲到. 另外有两个链接,可能会对你有用, Sessions and transactions 和 Open Session in View.
这次的DAO例子是基于接口的.很多工具, 像Hibernate已经提供了数据库的便携访问,所以我们不是为持久层的轻便而设计接口. 然而, DAO接口在较为复杂的应用中更有意义, 当有几个持久化服务被封装到一个持久层的时候, 我想在很多情况下你应该直接使用Hibernate或者JPA, 而使用外加的DAO层最好的理由是为了实现更高的抽象化(例如:定义方法名getMaximumBid()而不是无数次地重复session.createQuery(...)).
DAO接口
每一个持久化实体我用一个接口, 另外还有一个定义了泛型CRUD(增,删,改,查)操作的顶层接口.
以下是提供了类型参数关于某一实体的DAO接口,它继承了泛型接口:
基本上我们把通用的CRUD操作和具体业务相关的数据访问操作都分开了.(暂且不用理上面接口中的常量,如果使用Annotation,他们将会很有用.)然而,即使对于具体某个实体你只需要这些通用的CRUD操作,你也应该为它单独写一个接口.即使这个接口是空的.在你的controller code(控制器/业务代码)中使用一个具体的DAO是很重要的.否则当你要为这个实体引入具体的数据访问操作的时候,你将面临重构的问题.
一个Hibernate的(泛型DAO)实现
任何一个"可管理状态"的持久化服务都可以实现上面的泛型接口.首先,我们用Hibernate来实现这些泛型CRUD
我们需要禁止一些未检查转换(unchecked casts)编译时警告.因为Hibernate的接口是基于JDK1.4的.接下来是泛型CRUD操作的实现,很简单,最后一个方法(设计得)很好,它用了另一个JDK5.0的新特性-varargs(不定参数),它帮助我们在具体实体DAO里面创建Criteria查询.下面是一个继承了用Hibernate实现的泛型DAO的具体DAO例子:
下面是另外一个使用超类中具有不定参数的findByCriteria()方法的例子:
为DAO准备工厂
我们可以把一切都放到一个DAO工厂里面, 这个工厂不仅在DAO被创建的时候为其设置Session,还包含了一些嵌套类,用来实现只包含与业务无关的CRUD(CRUD-only)操作的DAO:
注意,这个工厂例子对于主要用一种持久化服务实现的持久化层都是适用的,例如Hibernate或者EJB3.0 持久化.如果你要混合使用持久化API, 例如, Hibernate和纯JDBC, 上面的模式只要改一点点,记住你是可以在一个特定的Hibernate DAO(用Hibernate实现的DAO)里面调用session.connection()的.或者可以使用很多Hierbate3.1 支持的SQL操作以避免用纯JDBC.
最后, 就是控制/命令处理代码(controller/command handler code)中的数据访问的样子了(选择你自己喜欢的事务划分策略,DAO中的代码不用改变)
准备用手动实现依赖注入的DAO
不用写工厂,你也可以实现这个例子.
用lookup准备(实例化)DAO
如果调用者在DAO被创建的时候没有提供一个Session,则可以调用HibernateUtil.getSessionFactory().getCurrentSession()作为一种折衷的做法.
所有的这些用于设置当前Session和创建DAO实例的方法(factories, manual injection, lookup)都有他们的优势和劣势.所以,使用你觉得最comfortable的一种.
DAO AS 受管理EJB3.0组件
把你的DAO超类改成无状态会话Bean的基类(现在你所有的具体DAO都变成无状态EJB了,他们都有一个业务接口了).这里只用了一个注解(Annotation),只要你乐意,你甚至可以把它移到一个XML部属描述符里面.然后你就可以使用依赖注入和获得由容器提供的"当前"持久化上下文.
只有在你把Hibernate作为持久化提供者的时候,这才会起作用.因为这个委托是Session API, 在 JBoss AS 里面你甚至可以直接获得一个已经被注入的Session,如果你使用不同的Java持久化提供者, 那么将依赖于EntityManager API而非Session. 现在把你的DAO绑定到控制器(这个控制器其实也是一个受管理组件):
以下是原文的部分跟帖
----------------------------------------------------------------------------
Granularity 10 Sep 2005, 05:14 anthony
Christian说:每个特定实体对应一个DAO接口,这样没有什么问题,但是可以考虑用包(package)
对于粒度(granularity)只有一句话说.对于基于100个持久化对象的项目来说,如果你的项目设计良好,每10-30个类你会用一个包.
用例应该是被每个包的根实体所驱动的(言下之意:定义每个用例都是基于每个包的根实体),所以你可以每个包都定义一个DAO接口.
例子:如果你有Order * -- 1 Client这样的对象关系,并且你要获得一个特定客户的所有订单?一个用例是只需要获得订单,另外一个需要获得订单和订单所属的客户.你会在ClientDAO还是OrderDAO里面编写这些操作呢?尽管你知道Client是作为根实体的最好选择(译者注:就是说即使你知道Client是作为根实体的最好选择,但是你还要想到底是在ClientDAO还是OrderDAO里面编码,因为到这DAO实现一步的时候你自己又有点迷糊了).
这个例子很简单,但是想一下对拥有4或6级对象图的复杂HQL查询,添加这些代码不会很容易,并且如果你有一个很大的开发团队,那将有很大可能会重复代码.
设计你的包的时候你需要很小心.
Transaction Management in DAOs 30 Oct 2006, 06:25 prashantbasawa
在DAO外面进行事务管理不是一个好的想法(做法).事务管理应该在DAO里面,我们可以用一个策略模式(Strategy Pattern)向DAO插入事务管理的行为.
如下定义一个接口:
一个实现接口的具体类
在以后,如果你像换成JTA事务,你可以创建一个新的事务策略.
还有,这些策略可以被设置到用HibernateDaoFactory.instantiateDAO(Class clazz)实例化的DAO里面,同时我们也可以在里面设置Session,我们还可以从一个属性文件里面取得策略信息(Strategy info),然后基于属性文件里面的属性你可以创建策略并且把它设置到DAO里面.
注意:Strategy也可以通过它的构造方法接收一个session.
--接着这个叫做prashantbasawa人又在下面说:
请忽略我在主题下面写的"注意"
Keep it simple 31 Oct 2006, 00:25 christian
当然,DAO不应该包含程式化的事务划分,不管你用什么时候的什么模式去隐藏它.
DAO最多可以为一个特定的方法接收一个事务上下文.这个问题用元数据能表达等更好,如:EJB3.0 Annotation(注解).
Re: Transaction Management in DAOs 13 Nov 2006, 02:12 prashantbasawa
对于持久化你能有多少个操作?只有3个,插入,更新,删除,这些你都可以实现一个超类使得没有重复编码.DAO里面不同的操作只是你查询各张表的时候用了不同的方式.我觉得对于查询数据你没必要使用事务,因为查询对数据库没做修改.
Re: Transaction Management in DAOs 14 Nov 2006, 05:19 christian
胡说八道!你必须保证读数据的正常ACID(原子性,一致性,隔离性,持久性),特别是当你想重复读取的时候保证隔离性.不要再在那里嚷嚷,"我真的不知道什么是自动提交".
Transaction scope 14 May 2007, 05:42 Olivier Billard
事务不应该由DAO开启和关闭, 下面是一个真正可靠的idea:
-在那种情况下(前面的Client-Order例子)你不能在一个事务里面包含几个DAO调用(这时候CRUD不能保证多个实体的原子性),这一点限制确实挺大的.
-在一个JTA事务中,你不能控制事务的生命周期,你可以能"参与"这个事务.
我想这两点说得很清楚,不要在DAO里面调用事务的being/commit方法.
当然,可能还有更多的观点.