DAO和Service分层之愚见

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

service层的方法有时逻辑非常简单，才会出现“明明如此神似 ”的情况，如果是稍微复杂的业务逻辑存在的时候，自然这两者之间的差别、关系就比较明显了，比如一个service层的方法需要引用多个dao的情况

一个要提供服务或是商业的项目会有不断的功能补充进来。项目越来越大越来越复杂，不分你都不知道怎么来继续编写和管理整个项目。

因项目而异。不能为了分而分。

开玩笑啦， 见谅。 之前也做过java web 开发，感觉很多时候就是过度设计， 特别是Dao 层和service 层， 在实际应用中往往是service 层的方法直接转调dao 层方法而已， 这样在service 层并没有体现多少逻辑， 反而造成大量的冗余代码， 可能有人以可维护性，可扩展性的理由有不同看法，  我的看法是绝大多数时候，dao 层逻辑改动service 同样会变动，反过来也一样， 这可能是由于service 层的粒度划分的问题， 但在基于数据库引用中service 粒度远远大于dao 层粒度的很少，而且dao层和service 层对象都基于接口我也持保留意见， 接口更多是对外提供，对内如果结构相对复杂且要清晰划分规则的情况当然应该推荐基于接口的设计， 对于dao，service这种本来就是基于业务的东西就是要保持敏捷的特征， 到处都是针对数据库操作的接口没有多大复用的意义， 给维护带来的更多的是负担，与初衷背道而驰， 别忘了如果是对外提供接口还有直接的web 层可以处理。总之这个东西没有统一的规则， 有人说好，有人说不好。

我也知道分层 了额

就是想了解一下大家对这两层如何”分“才是更解耦的。更有效的

恩。 是的    老兄说的很在理。 学习了。谢谢

建议楼主看一看<<企业应用架构模式>>, 里面讲到了事务脚本,  领域对象模型,  表模块三种逻辑层架构模式,  估计会对分层问题有些新的认识。本人认为目前国内的开发中98%都在使用的三层架构方式实际上是面向对象设计中的一种极其不好的实践，本质上是打着面向对象的旗号做面向过程的勾当。但是由于这种架构方式上手简单，学习成本低廉，非常容易理解，所以为广大公司津津乐道。对于软件架构的分层方式，是一个没有真正正确答案的问题。学习，学习，在学习。。。慢慢就知道了。

service层，可有可无的。但是如果希望项目便于以后维护，层次分明还是有必要的。

看过一点东西，就这么决然的否定分层，以为自已很NB吗？以为自已很了解OO吗？还国内98%是极其不好的实践。不同的场景使用不同的架构。你这个话题，一引申多了就是其它的东西，有些东西本来就无所谓对错。