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

我看过AppFuse的整体结构，发现DAO和Service的功能有重复的地方，就搞得不是很明白，总觉得Service是多余的，难道controller（或action）层就不能调用Dao层了么？
  还有据gigix居然说连Dao都不需要了，直接在controller（或action）使用Hibernate的Session！

看你自己如何去看待三层结构的开发模式了。我是主张将DAO和Service分开。DAO实现对数据库的操作，Service实现业务逻辑的封装，数据库操作只是业务逻辑的一部分而已。

除了数据库操作,可能还有其他逻辑处理.

当然怎么用看个人的习惯而已.

都放在action里面程序也能运行.

gigix说的DAO可以不要是一种“偷懒”的做法，因为对于大多数web应用来讲，基本上都是简单CURD操作，这样很容易造成你说的重复情况。既然都是简单的CURD，那就可以将getHibernateTemplate()直接写到service里，这样写程序就比较方便了。

但是在实际应用中，我还是使用Service+DAO，麻烦是麻烦了一点，但分层能相对清晰一点。

在DDD模型中，service相当与一个facade，所以把数据库操作放到domain和DAO中我觉得还是必要的。

丢弃DAO的做法我赞同。
可以在Serviceimpl里面直接getHibernateTmplate(),
至少可以省事了。

有些简单的功能的确看着是重复的，特别是CRUD
从项目的角度来看，还是统一比较好。  我觉得还是分开

DAO本来的目的就是抽象数据访问逻辑，
而这种逻辑Hibernate已经封装的很好了

所以使用Hibernate就不再需要DAO，可以省掉一大批class，不好吗？

做小东西的时候会有些麻烦，我个人的建议是：
小东西（不需要升级版本的）可以省掉DAO层，直接在service里写，大的东西或者需要升级的还是老老实实的写吧，麻烦一点，不过以后回过头来看是很值得的

我也觉得，如果用了hibernate，ＤＡＯ是可以省略，能少写一点儿ＣＯＤＥ就少一点儿．但是，我们还是写了一个manager作为业务逻辑．service主要是为了业务逻辑的facade用的．

麻烦是麻烦了点，但是结构清楚，考虑到以后的维护和灵活性还是这样来了，理解起来很舒服