DAO和Service分层之愚见

今天在鼓捣自己的小项目时候,突然想到了为什么要在这么一个项目中使用明明如此神似的DAO层和Service层。

原文

自从大一暑假步入J2EE神殿以来,经常都是学习如何做而很少思考为什么这么做(不够深入还是硬伤啊),于是乎就网上查找各种前辈们的见解和资料。经过整理和思考,对这个问题好像有了点自己的想法,但是又不知道自己的想法是否合理,又于是乎发在这个大牛云集的地方,想倾听一下大家的意见。

以下是自己的看法:

  • DAO层面向事务和持久层。它实现了连接数据库CRUD等的底层细节
  • Service层面向功能和业务逻辑。它通过调用一个或多个DAO中的功能点(方法)来组合成为一个复杂的业务逻辑

在大多数情况下,DAO层与Service看起来会有很大的雷同。这是因为在大多数情况下Service的需求不是很复杂,在Service里面不需要完成过多的包装处理就可以直接调用DAO的方法执行数据请求处理,比如Save、Delete、Update、Select等。然而为了项目各层的松耦合、扩展性,在开发中Service一般不能直接接触持久层(数据库),必须通过DAO访问持久层。

有的时候只是为了分层清楚,为了将来scale up的时候方便我们才把service和dao分开,其实没必要分开的 。在小规模的应用中,没有Service,完全是DAO或BO也是可以接受的。

但是开发人员总是追求更远大的目标,总是希望现在开发的项目在将来能够可持续发展,因此DAO和Service分层也就显然合理了

我总是乐于帮助需要帮助而我力所能及的人。希望大牛们路过,发现小弟这个有什么问题或者有其他的见解发出来让小弟见识见识哈

一番讨论之后,我感觉很在理的一些见解

  • dao只面向持久层,事务层应该在service层。
  • service层面向事务和业务逻辑,一个业务不仅可以调用多个dao,也能调用多个service完成业务功能。事务一般不会在DAO层,一般在Control中,或者在service中!
  • DAO层面的目的是试图在表结构发生变化的时候尽量去少改动代码。这些东西对于一次性的项目或许是没什么意义的。但是如果产品存在扩展和完善的需求,这样做的目的就显现出来。只所以分层的设计思想在很多时候并没有体现出优势,主要原因就是规划和设计不足导致。

写于三四年后

当年还是菜鸟的自己,还真是初生牛犊不怕虎,在技术论坛里面大放厥词,直面大众狂喷。O(∩_∩)O哈!