有了DAO，为什么还需要Service（Manager等等）？

不师常俗,不法常可.框架之事，因为之备.

有性格？呵呵

一句话：具体问题具体分析

如果是crud的话，就不用这么麻烦了，偶有一个通用的crud模块，加一个新的crud功能模块的时候只需要写一些配置信息和几个页面，基本上不用写什么代码。

DAO层做的事情与SERVICE层做的事情还是有区别的。
DAO层负责与具体的数据打交道，这些数据不一定来自数据库，有可能来自某个CACHE系统，或者来自搜索引擎，对于多数据库的应用，DAO层可能还要考虑来自多个库的数据库的综合等问题。

SERVIER层：是具体的业务逻辑，关键是这些业务逻辑是可重用的。与业务表示层的ACTION无关。不同的ACTION可以调用同一个业务逻辑。

ACTION：简单的应用ACTION就可以直接调用SERVIE层了，但复杂的企业级应用，在ACTION与SERVICE层之间应该还有一个业务流程层，处理具体的业务流程，注意，SERVICE层关注的的业务逻辑问题。其它诸如事务、权限控制可以考虑在业务流程层中处理。

嗯，是的! service层是业务层，DAO是操作持久层的接口，在service中调用DAO来实现数据库操作。 因为你在service中可能调用多个DAO执行业务操作，这样在JTA环境里可以把多个DAO纳入到同一个事务中!

个人意见，说出来不要有人打我。

如果你们工作的组里面没有人可以回答这个问题，那么就按你们自己最喜欢的方式来写程序。如果在没有发现这些框架的好处的时候来和程序员说要如何如何的，最后的结果往往还是不说一样，因为做的时候基本上只是有一个形，没有达意，形式上符合了要求，但是其精华已经不在了，分层的好处在需要用到的时候基本上体现不出来了。

总之，按工作组里最流行的方式来编写程序，不管是开始，还是到以后，都会是最好的。（当然，如果没有一个一致的方式来写是绝对不行的）

appfuse 里面的service 层说实话，就是对DAO 层的一个再包装，“但是”，如果你的商务逻辑很复杂，那就不仅仅是CRUD 操作了，会有很多复杂的业务逻辑，DAO 层是对数据库表结构的一个直接的隔离操作层，业务逻辑有时牵涉的面很广，放在抽象逻辑性质的service层会比较好，维护，理解，管理起来也比较方便。作一个优质的系统，不仅从技术方面考虑，还需要从成本，习惯，思维方式，业务逻辑模型以及团队开发维护等诸多方面考虑。

果然！