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

未必吧，
DAO的存在是为了隔离持久层的真实策略，
Hibernate仅仅隔离数据存放在哪种数据库，
而数据的持久策略还包括数据由哪些方式存放（是数据库还是XML或者其他）
数据是否缓存，采用那种缓存方式，
数据库存取的实现方式（Hibernate还是JDBC）等等
这些策略的采取对服务层应该是透明的，
对于大型的项目来说，
即使采用了Hibernate，DAO这一层还是不可少的

DAO仅仅是CRUD object的 动作

Service（Manager）是从业务角度出发，对什么样的数据进行什么样的处理

一开始我也这么觉得 后来写了小系统 觉得两者功能不一样 dao是为什么存储数据的 比如现在用hibernate 以后可能改为jdbc或者其他的也比较方便
service是单纯的进行业务逻辑处理调用Dao来持久数据
所以DAO和service还是应该要独立的！

先看看这个帖子,避免重复讨论

http://forum.iteye.com/viewtopic.php?t=11712&postdays=0&postorder=asc&start=0#67222

是啊,这个话题完全没必要再讨论了.

说来说去也没什么结果. 用DAO的还在用,不用DAO的打死还是不用

gigix？别听他瞎说。
一个企业级的应用servcie layer是最复杂的，你说的appfuse只是一个为了展示各种opensource技术的一个demo，没有business logic，像银行，社保这类的应用你直接用dao或者不用service/dao试试，维护的时候累死你。
至于简单的应用不在讨论之列，用javabean + jsp一样可以搞定。

好象没有什么必须的问题吧,一切都看你的应用如何了,如果系统小,维护或者移植比较少,或者业务模块简单,不分开也没有什么问题.但是从维护和开发的角度,个人觉得还是分开比较好.

我真是晕倒，这么多人的意见都不一样。
  我的意思当然不是不要dao，我以前做的是dao和service都要，但是Controller层（或action层）可以调用dao（对于简单情况，比如：删除一条记录、增加一条记录等等），对于复杂的业务操作，则需要另起service－－也就是controller层可以调用dao层和service层。我以前做得好好的，没有什么问题。对于简单的操作，通过service层调用dao层来完成，有必要么？
  AppFuse我不是很看好：dao层不够简洁，service层和dao层功能太过重复了，还有ant脚本居然写了1000多行，估计看得懂还挺费劲的。

同意，如果业务逻辑复杂，那需要一个专门的业务层来处理业务，这个时候service层就很有必要，如果只是一些简单的逻辑，比如，新增。。。一个页面就能搞定的东西，或者稍微有一些逻辑，完全没必要，action里直接调用DAO好了。不要为了分层而分层。

appfuse？呵呵，这个框架可是为很多人做了关键性指导作用啊，呵呵，比如说我：）
我说过appfuse只是对一些流行的opensource的framework的一个综合技术展示，里面service和dao根本就没有什么逻辑。
他分层只是为了展示一个完整的多层结构的基本的结构，那些逻辑用javabean都能搞定了。所以最重要的还是自己在appfuse的基础上扩展，发挥自己的水平，师傅引进门，修行靠个人吧。