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

儅系統很大時，你就會覺得將層次細分所帶來的好處，不會滿世界找你的業務邏輯代碼，我覺得在Dao上加個Facade是很有必要的！

同意这个观点,就好象写asp程序,一个页面处理所有的事,一旦系统完成，小系统还好，就算重写也不难(有时候重写更简单),但系统复杂了,要想再改,那会是件十分痛苦的事情.还是喜欢清晰的层次感!

个人认为如果不是“很小很小的一次性项目”，DAO层还是有必要的，因为DAO层隔离了持久化实现，如果直接在Service层调用HibernateTemplate，那么如果将来更换持久层框架，所有的Sevice层代码都需要修改。

我在项目的设计是，首先定义一个通用DAO接口，该接口暴露所有的（足够细粒度的）持久化操作（如；CRUD、批处理、列举、根据条件查询等），然后用一个实现类提供实现，Service使用的是DAO接口，所有实体对象（Entity Bean/PO）不会有各自的DAO，这样做一来让DAO“职责分明”，除了CRUD等持久化操作，任何业务逻辑都不做，二来也不需要为每个实体对象建立各自的DAO而增加Coding量。所以业务逻辑放在Service层做，业务逻辑处理过程中调用DAO接口的方法实现各种持久化或查询操作。

这样设计，各层“职责分明”，Service负责业务，实体对象负责Data Store，DAO负责CRUD，将来即使因为技术需要而更换持久层框架，只有DAO设计得合理和足够Fine-Gianted，Service层就无需做任何更动。

至于某些跟实体紧密联系的业务逻辑，比如每个数据字段的有效性校验，就 可以直接封装在实体对象中，避免出现Duplicated Code。

从层次结构上来说，没Hibernate的时候DAO很有必要，有Hibernate的时候DAO就不需要了，可以做的项目少，至今没遇到要换持久层的情况，我想就算是换99%也只是换数据库，Hibernate完全搞得定，对于必须要用非数据库持久方式的项目，一开始就不应用Hibernate

看实际情况吧，我们的项目将来就有可能用EJB3取代Hibernate

hibernate 本来就是与Dao同一个层次的

就因为有了DAO 所以才有SERVICE

不赞同，能丢的是因为没有业务，如果有业务呢，难道又要把业务和操作数据库整合到一起？那不是后退么……
ps：当然如果是纯粹的CRUD，完全没业务可言，那少写点代码无所谓。只是要扩展就麻烦些。
再ps：Norther，好像在matrix见过此ID。

DAO层和SERVICE层还是应该区分开来，个人认为DAO层应该是实现取数据的操作，尽可能结构简洁，有利于代码的复用；SERVICE层可以根据DAO层取出的数据做业务逻辑操作，另外SERVICE层也不只是访问数据库操作，还有其他例如生成图表，导出报表等等的操作，所以有一个独立的SERVICE层来集中处理系统业务逻辑还是必要的。

这个就是设计的技巧拉。为什么很多人都回用到Service（Manager等等）？ 这个是因为方便以后的以后的维护与升级，从细的方面来说这个确实是设计者的精明之处，其实很多时候DAO实现对数据库的操作，但也有可能增加一些业务逻辑，而Service层确实是实现业务逻辑的封装。而action直接调用Service层那就是很方便了。这样那个框架就是很清晰拉。当然你那样想未必不可，但是从框架的清晰度来说，也比较混乱一点。前人种树，后人乘凉啊！！！！！！！！！！