思考轻量级JEE Web程序架构

注:标题写得有点夸张,这是本人的文学修养问题,不在讨论范围之内。这里的前提是使用贫血模型模式和轻量级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层进行了解的,不是吗?

你可能感兴趣的:(思考轻量级JEE Web程序架构)