Hibernate Sync DAO封装小结

转一篇我在项目BLOG上写的文章。搞Hibernate Sync花了一段时间，算小结一下吧。

Hibernate Sync虽然不是很强大，但是，对于一般的简单应用来说，也是足以应付了。

最近在研究DBUnit，想把单元测试引入到咱们的数据库DAO测试中来。做了一些试验，我也对DBUnit做了一些封装，以后写基于DBUnit 的TestCase就像写Junit的单元测试那样简单:) 如果有需要的话，我可以整理一下关于数据库DAO测试的内容，给大家汇报一下:)

在做例子的过程中，我使用Hibernate Sync来生成DAO方法。为什么选用Hibernate Sync，因为它简单，并且生成的类恰好够用，并且也适合在它上面做开发，建模更加复杂的ORM映射。

好了，闲话不讲。本文的主要内容是研究Hibernate Sync DAO的设计，并通过代码示例来探讨Hibernate Sync对Hibernate的良好封装。

它的DAO继承体系如下：
可 以看到_BaseRootDAO是所有DAO的基类，_RootDAO基本上可以忽略，没有实质作用。BaseBugDAO：提供对于Bug实体的常用增 删改查操作。BugDAO主要是给我们用的，如果我们需要写其它的DAO方法，可以写在这个里头。另外，它也遵循普遍的OO原则，对于BugDAO类，也 实现了相应的BugDAO接口，在iface包下。（按照我们的代码编写规范，这样定义接口名称可是不行的。我们需要把BugDAO接口改成 IBugDAO）。

它的Entity继承体系如下：

可以看到，在Hibernate中，实体是比较纯粹的，就是实现了Serialize接口的对象，并不会在该实体对象中含有很多CRUD操作。我认 为这是正确的设计。回过头来，BaseBug就对应着我们的数据库，我们不用去修改BaseBug。Bug对象，我们可以增加属性和方法，可以将其改造成 有血有肉的领域对象。这个后面再说。

应该说，DAO做到这个程度基本上已经可以了。它让我们减少了编写DAO的工作量，同时在代码质量上是有保证的。在整个DAO层次中，最为核心的类 就是_BaseRootDAO。研究这个类，可以让我们更加了解Hibernate的使用方式：Configuration -> SessionFactory -> Session (ThreadLocal)
自己读代码嘛，从下往上看看_BaseRootDAO是如何封装Hibernate的。

java 代码

public java.util.List findAll () {
 Session s = null;
 try {
   s = getSession(); //首先去取得Session。跟踪进去
   return findAll(s); //然后通过Session.find(×××)来实现findAll操作，这步下去是Session使用方面的东西，有兴趣自己跟踪。
  } finally {
   closeSession(s);
  }
 }

算了，在这上 面分析代码太麻烦。如果有兴趣的话，直接跟踪代码进去看看。就知道它什么时候去创建SessionFactory，什么时候去new Configuration，然后什么时候去config，还可以看到它是怎么支持多个SessionFactory的，以及它是怎么重用Session 的，凡此总总。

在使用Hibernate Sync过程中也遇到一些问题：

1. 关于Content is not allowed in prolog问题。这个问题困扰了我2个小时，最终发现我根本就没有去配置Hibernate的配置文件的名称。具体名称当然是在 _BaseRootDAO中，有个getConfigurationFileName()方法。这个问题和我google到的答案完全是不一致的，最终还 是分析出来的。

2. _BaseRootDAO对于单个操作都是事务的，比如save，update, delete等。但是对于要批量delete，它的实现是一个一个调用单个delete。因为不是在一个事务里头，而是在N个事务里头，可能会有一些性能 上的问题。和一般的要求还不太一致:)

使用就很简答了。以BugDAO为例：List actual = new BugDAO().findAll(); //完全不用去写什么getSession方法，很简单。