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