HibernateDaoSupport的优缺点

HibernateDaoSupport的优缺点

编写Dao类的时候尽量不要使用Hiberenate和Spring对Hibernate的支持：

现在我们在编写DAO的时候普遍都是直接继承spring对hibernate的封装类 HibernateDaoSupport， 然后使用该类提供的诸如saveOrUpdate(), saveOrUpdateCopy(), find()等等。另外，在使用excute()方法实现一些更复杂的hibernate功能的时候还会使用hibernate的类，诸如Query, Session, Type等。这样直接使用spring和hibernate的类存在的问题在于，你的代码将不得不依赖与spring和hibernate的某个版本。比如说，现在hibernate3出来了，改动挺大，实际上最要命的是包结构，hibernate2的包结构是net.sf.hibernate.*，然而 hibernate3是org.hibernate.*。同样，spring为了支持hibernate3，包名也改为 org.springframework.orm.hibernate3.*。假如，你现在新开发一个项目，这没什么关系，如果是升级一个项目问题就来了。如果你希望将你的一个项目从hibernate2升级为hibernate3，你不得不修改DAO中所有对hibernate和spring- hibernate的引用。如果你的代码中出现hibernate2与hibernate3不兼容的方法和类，比如saveOrUpdateCopy() （在hibernate3中已经没有了）,你还将不得不改写。那么你可能会说，我不会这样升级。如果你的软件生命周期有好多年，hibernate升级到 4，升级到5，你还是依然使用hibernate2？如果你以这种方式开发一个平台，你能要求所有使用你平台的软件项目都只能使用hibernate2？更进一步说，我现在开发一个产品，今后的客户将是成千上万。经过1、2年我需要升级了，这时我的升级包有几十M，几乎把所有的DAO都换了个遍，这样的升级无异于重装。

分析原因:是我们项目中的DAO依赖于hibernate和spring，因为我们对它们的使用是继承，是一种很强的关联，就是一种依赖.

解决方案一:我们只需要稍微进行一些调整，就可以解决这个问题，那就是不使用直接继承，而使用接口进行分离。可以使用Facade模式，先建立一个叫 BasicDao的基础类，从名称我们可以看出，它是所有DAO的基础类，实现DAO操作所需的所有诸如save()、delete()、load()、 query()等方法，除了一些基本的方法，诸如翻页查询、getCount、解析查询条件形成HQL语句等功能也在这里实现，但是不要使用与 hibernate或spring有关的任何方法和类。同时，BasicDao调用一个叫DaoSupport的接口，DaoSupport的接口则是提供持久化所需的基本方法，最原始的元素。然后，我为DaoSupport接口提供各种不同的实现，比如hibernate2的实现 DaoSupportHibernateImp、hibernate3的实现DaoSupportHibernate3Imp，整个结构如下图所示。 BasicDao可以使用hibernate或spring提供的方法，但是不是直接使用，而是通过调用DaoSupport的实现类来使用。然而 BasicDao到底是使用的那个实现类，我们通过spring的IoC，通过配置文件来决定到底使用哪个实现。同时，BasicDao也不要使用诸如 SpringContext的类来实现IoC，而是通过建立setDaoSupport()和getDaoSupport()方法，然后在spring配置文件中建立引用。