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 分层也就显然合理了

 

 

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

 

========================================================================================

 

 

我感觉很在理的一些见解 写道

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

 

评论

48 楼 itlangqun 2011-04-06  

不错，很简短但我需要。曾经我也纳闷过如此神似为何要这样分层？
咦，楼主给答案了。

47 楼 java-xb 2011-04-06  

dao层不应该要事务，把事务统一放到service中，这样比较好。
举个例子：比如 Userdao和Cardao，在一个service中需要同时修改 user表中car表中数据，这样就需要一个事务来保证user表更新的同时，car表也在更新，所以如果一个servic中用到了一个以上的dao，就应该把事务放到service层中来。

46 楼 dugucanhong 2011-04-06  

xugang8289 写道

建议楼主看一看<<企业应用架构模式>>, 里面讲到了事务脚本,  领域对象模型,  表模块三种逻辑层架构模式,  估计会对分层问题有些新的认识。本人认为目前国内的开发中98%都在使用的三层架构方式实际上是面向对象设计中的一种极其不好的实践，本质上是打着面向对象的旗号做面向过程的勾当。但是由于这种架构方式上手简单，学习成本低廉，非常容易理解，所以为广大公司津津乐道。对于软件架构的分层方式，是一个没有真正正确答案的问题。学习，学习，在学习。。。慢慢就知道了。

这本书我要去读一读。

45 楼 bugu1986 2011-04-06  

jackra 写道

DAO层面的目的是试图在表结构发生变化的时候尽量去少改动代码。
这些东西对于一次性的项目或许是没什么意义的。但是如果产品存在扩展和完善的需求，这样做的目的就显现出来。
只所以分层的设计思想在很多时候并没有体现出优势，主要原因就是规划和设计不足导致。

这位也说的很有见地

44 楼 bugu1986 2011-04-06  

业务逻辑不多确实可以，玩玩的项目是可以不分的，否则不光要分service和dao，可能会分更多，业务层已经很复杂了，就不能让人家操心crud了，做平台的要把这些都做了，再提供出抽象的业务，因为业务不光是crud啊。

成然，我上学的时候也是楼主这样的想法，工作一年多后就不这么想了。呵呵

43 楼 a657439380 2011-04-06  

分层应该只是维护方便一点吧，当然你也可以不分层。。。。

42 楼 xu-zhx 2011-04-06  

怎么舒服怎么写就行了，各种层都是浮云，浮云。。。。

41 楼 com0606 2011-04-06  

HelloJimmy 写道

大学里还是好好学习下数据结构、操作系统等基础知识吧。。。。。框架什么的，这些都是浮云，工作中慢慢理解。

我们承认，这些课都十分的有用，但是我们至今无法学到其有用的地方。还得指望自己摸索

40 楼 用手踢球 2011-04-06  

s929498110 写道

yangguo 写道

s929498110 写道

yangguo 写道

你可以连dao层也不要，直接在action上访问数据库。
或者连action都不要，直接在jsp上面写逻辑。
看你开发的什么。

  
汗啊。 老兄你这个看起来怎么那么奇怪呢

看起来奇怪的话，只能说明你还没入门。

好吧， 绝世高人。。。
或许“直接在jsp上面写逻辑” 是J2EE的最高境界
俺这个凡夫俗子还真没入门

yangguo说得很对，只要是看你的需求的！

39 楼 horse88sky 2011-04-06  

xugang8289 写道

建议楼主看一看<<企业应用架构模式>>, 里面讲到了事务脚本,  领域对象模型,  表模块三种逻辑层架构模式,  估计会对分层问题有些新的认识。本人认为目前国内的开发中98%都在使用的三层架构方式实际上是面向对象设计中的一种极其不好的实践，本质上是打着面向对象的旗号做面向过程的勾当。但是由于这种架构方式上手简单，学习成本低廉，非常容易理解，所以为广大公司津津乐道。对于软件架构的分层方式，是一个没有真正正确答案的问题。学习，学习，在学习。。。慢慢就知道了。

看过一点东西，就这么决然的否定分层，以为自已很NB吗？以为自已很了解OO吗？还国内98%是极其不好的实践。不同的场景使用不同的架构。你这个话题，一引申多了就是其它的东西，有些东西本来就无所谓对错。

38 楼 mdream 2011-04-06  

service层，可有可无的。但是如果希望项目便于以后维护，层次分明还是有必要的。

37 楼 xugang8289 2011-04-06  

建议楼主看一看<<企业应用架构模式>>, 里面讲到了事务脚本,  领域对象模型,  表模块三种逻辑层架构模式,  估计会对分层问题有些新的认识。本人认为目前国内的开发中98%都在使用的三层架构方式实际上是面向对象设计中的一种极其不好的实践，本质上是打着面向对象的旗号做面向过程的勾当。但是由于这种架构方式上手简单，学习成本低廉，非常容易理解，所以为广大公司津津乐道。对于软件架构的分层方式，是一个没有真正正确答案的问题。学习，学习，在学习。。。慢慢就知道了。

36 楼 s929498110 2011-04-06  

jackra 写道

DAO层面的目的是试图在表结构发生变化的时候尽量去少改动代码。
这些东西对于一次性的项目或许是没什么意义的。但是如果产品存在扩展和完善的需求，这样做的目的就显现出来。
只所以分层的设计思想在很多时候并没有体现出优势，主要原因就是规划和设计不足导致。

恩。 是的    老兄说的很在理。 学习了。谢谢

35 楼 s929498110 2011-04-06  

我也知道分层 了额

就是想了解一下大家对这两层如何”分“才是更解耦的。更有效的

34 楼 beyondsc 2011-04-06  

s929498110 写道

beyondsc 写道

早就上过当了， 还在被这些破东西骗啊？

 
表示朋友你说的话。 小弟不太明白啊。。。

我就是想看看对DAO和Service之间的分层和解耦合理解的是否有问题，希望各路高手评论一下而已额

开玩笑啦， 见谅。 之前也做过java web 开发，感觉很多时候就是过度设计， 特别是Dao 层和service 层， 在实际应用中往往是service 层的方法直接转调dao 层方法而已， 这样在service 层并没有体现多少逻辑， 反而造成大量的冗余代码， 可能有人以可维护性，可扩展性的理由有不同看法，  我的看法是绝大多数时候，dao 层逻辑改动service 同样会变动，反过来也一样， 这可能是由于service 层的粒度划分的问题， 但在基于数据库引用中service 粒度远远大于dao 层粒度的很少，而且dao层和service 层对象都基于接口我也持保留意见， 接口更多是对外提供，对内如果结构相对复杂且要清晰划分规则的情况当然应该推荐基于接口的设计， 对于dao，service这种本来就是基于业务的东西就是要保持敏捷的特征， 到处都是针对数据库操作的接口没有多大复用的意义， 给维护带来的更多的是负担，与初衷背道而驰， 别忘了如果是对外提供接口还有直接的web 层可以处理。总之这个东西没有统一的规则， 有人说好，有人说不好。

33 楼 accphc 2011-04-06  

因项目而异。不能为了分而分。

32 楼 kanny87929 2011-04-06  

一个要提供服务或是商业的项目会有不断的功能补充进来。项目越来越大越来越复杂，不分你都不知道怎么来继续编写和管理整个项目。

31 楼 kehua430 2011-04-06  

service层的方法有时逻辑非常简单，才会出现“明明如此神似 ”的情况，如果是稍微复杂的业务逻辑存在的时候，自然这两者之间的差别、关系就比较明显了，比如一个service层的方法需要引用多个dao的情况

30 楼 jackra 2011-04-06  

DAO层面的目的是试图在表结构发生变化的时候尽量去少改动代码。
这些东西对于一次性的项目或许是没什么意义的。但是如果产品存在扩展和完善的需求，这样做的目的就显现出来。
只所以分层的设计思想在很多时候并没有体现出优势，主要原因就是规划和设计不足导致。

29 楼 shansun123 2011-04-06  

yangguo 写道

你可以连dao层也不要，直接在action上访问数据库。
或者连action都不要，直接在jsp上面写逻辑。
看你开发的什么。

拉轰哥~