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

 

评论

8 楼 JetMah 2011-04-06  

horse88sky 写道

引用

DAO层 面向事务和持久层 。 它实现 完成 了 连接数据库 CRUD 等的 底层 细节

dao只面向持久层，事务层应该在service层。

引用

Service层 面向功能 和业务逻辑 。 它通过 调用一个或多个DAO 中的功能点 (方法 ) 来组合成为 一个复杂的 业务逻辑

service层面向事务和业务逻辑，不仅可以调用多个dao，也能调用多个service完成业务功能。

ps:这个没有什么好讨论的，基本上有两派。多数派为service和dao分层。少数派为不分。你选哪一派呢？

个人觉得实际项目中需要根据自己的具体情况来选择，小一些的项目不分反而好，有空可以看看play 框架。当然如果是初学的话就另当别论了。

7 楼 tom&jerry 2011-04-06  

s929498110 写道

horse88sky 写道

引用

DAO层 面向事务和持久层 。 它实现 完成 了 连接数据库 CRUD 等的 底层 细节

dao只面向持久层，事务层应该在service层。

引用

Service层 面向功能 和业务逻辑 。 它通过 调用一个或多个DAO 中的功能点 (方法 ) 来组合成为 一个复杂的 业务逻辑

service层面向事务和业务逻辑，不仅可以调用多个dao，也能调用多个service完成业务功能。

ps:这个没有什么好讨论的，基本上有两派。多数派为service和dao分层。少数派为不分。你选哪一派呢？

多谢指定！
   我也不是讨论。 就是想加深一下自己的知识见解、 还有就是抛砖引玉 

引用

service层面向事务和业务逻辑，不仅可以调用多个dao，也能调用多个service完成业务功能。

这个确实是这个意思

引用

事务层应该在service层

这个该怎么理解额  
Transaction和Session不是都在DAO层的吗？

举个例子：银行转账，一账户增，一账户减，DAO里是对某个账户的操作，在Service里要两次调用DAO（一账户增加，一账户减少），这两次操作要么都完成，要么都不完成，所以事务一般来讲是在Service里的。

6 楼 skzr.org 2011-04-06  

s929498110 写道

这个该怎么理解额  
Transaction和Session不是都在DAO层的吗？

这个事务一般不会在DAO层，一般在Control中。或者在service中！

5 楼 thzthbthy 2011-04-06  

因为大家公司的项目没有小到 不用分层就能快速开发的地步，所以分了

4 楼 s929498110 2011-04-05  

horse88sky 写道

引用

DAO层 面向事务和持久层 。 它实现 完成 了 连接数据库 CRUD 等的 底层 细节

dao只面向持久层，事务层应该在service层。

引用

Service层 面向功能 和业务逻辑 。 它通过 调用一个或多个DAO 中的功能点 (方法 ) 来组合成为 一个复杂的 业务逻辑

service层面向事务和业务逻辑，不仅可以调用多个dao，也能调用多个service完成业务功能。

ps:这个没有什么好讨论的，基本上有两派。多数派为service和dao分层。少数派为不分。你选哪一派呢？

多谢指定！
   我也不是讨论。 就是想加深一下自己的知识见解、 还有就是抛砖引玉 

引用

service层面向事务和业务逻辑，不仅可以调用多个dao，也能调用多个service完成业务功能。

这个确实是这个意思

引用

事务层应该在service层

这个该怎么理解额  
Transaction和Session不是都在DAO层的吗？

3 楼 horse88sky 2011-04-05  

s929498110 写道

horse88sky 写道

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

 
朋友怎么复制粘贴我的啊， 不留下点东西就走了？

我是先占位再写东西。

2 楼 s929498110 2011-04-05  

horse88sky 写道

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

 
朋友怎么复制粘贴我的啊， 不留下点东西就走了？

1 楼 horse88sky 2011-04-05  

引用

DAO层 面向事务和持久层 。 它实现 完成 了 连接数据库 CRUD 等的 底层 细节

dao只面向持久层，事务层应该在service层。

引用

Service层 面向功能 和业务逻辑 。 它通过 调用一个或多个DAO 中的功能点 (方法 ) 来组合成为 一个复杂的 业务逻辑

service层面向事务和业务逻辑，不仅可以调用多个dao，也能调用多个service完成业务功能。

ps:这个没有什么好讨论的，基本上有两派。多数派为service和dao分层。少数派为不分。你选哪一派呢？