Javadream

注：标题写得有点夸张，这是本人的文学修养问题，不在讨论范围之内。这里的前提是使用贫血模型模式和轻量级JEE Web，没有考虑分布式。

这些天在看Hibernate的资料，除了对它的强大感到惊人之外，更多的就是烦恼，因为太多本来确定的理论现在都变得相当站不住脚，而且有些东西百思不得其解。这得从DAO层开始讲起，一般的架构是这样的：
     Web层
      |
   Service层
      |
     DAO层
      |
    数据库

因为DAO层主要负责对象持久的操作，而Service层则是除持久操作外操作，所以各自分工，层次分明。但是因为在按各种条件检索数据的时候，Service层需要向Web层提供相应的接口，比如说接用户名查订单需要一个接口，按时间查订单需要一个接口等等，但是这样使得DAO层同时也必须提供同样的接口，这样，当有新的需求时就要添加两个接口，而且通常Service层只是简单的调用一下DAO层而已。

而另有一种方法就是Service类继承DAO类，覆盖相应的方法，这使得只修改Dao的方法就可以了。但是就有了问题，因为Service层的接口要求的参数和DAO层的参数会不一样，这造成重载了相应的方法而不是覆盖相应的方法，也就是说Service类无端多了很多接口，使得调用有些混乱。

从实际来看，常用后面那种方法，而且和上一层程序员搞好默契，哪些方法可以用，哪些不可以。但是这带来的问题就是一不小心调用错了就麻烦了。而前一种虽然修改麻烦一点，但至少使得Service层是干净的接口，没有不用得上的接口。

其实在日常的开发中总是这样认为，DAO有没有一个万能的接口可以用于检索对象？就旭上面所说的，按用户名查订单等这样的操作，有没有一个通用的接口去实现呢？DAO不是做不到，而是开发这样的功能相当复杂，而且难以重用，似乎这是一个理想，一个难以实现的理想了。

从上面的讨论中我们可以看得到，DAO就是持久层，他负责对象的CRUD，而且我们希望有一个通用的检索对象的接口。

终于，我们的Hibernate横空出世了（超级赛亚人？）。他的Session实现了对象的CRUD，与此同时接供了基于HQL的Query接口，用于按条件检索对象，从这个意义上来说，他就是一个DAO实现，我们可以直接在Service层使用Hibernate做为的DAO。

可是为什么还有这么多人要在Hibernate之上建立DAO呢？无非就是做一个可更换持久层的系统（如JDO），又或者把Hibernate的一些Session操作隐藏起来，使得Service层的代码更为简洁明了。对于后面的说法还可以说得过去，可是前面的讲法就不妥了，因为通用的检索接口各个ORM实现都不相同，那么DAO很难做得到通用，这就又回到前面没有Hibernate之前的困境了；而与此同时，使用DAO也会有一些问题，就是必定是跨了多个Session进行的操作，那么在Update操作时就会把整个对象（这个对象是游离态的）进行所有字段的进行更新，实际上只有一两个字段被修改了，对于一些计数操作，这样的方式的性能相当差劲（比如说一篇文章有多少人阅读过了这样的计数）。

其实会这么样，我会直接在Service使用Hibernate做为DAO，在大多数中小型应用中，很少（几乎没有）有人会要求更换持久层中间件的，所以根本不用担心，而且维护也并没有想象中复杂，因为始终还是得对新的DAO层进行了解的，不是吗？