DAO层当前还应该继续存在

DAO层当前应该存在，原因如下：
1,必尽还是关系数据库的时代，还有对于数据库访问不同数据库还是有存在差异，用DAO层实现来解决差异，除非ORM足够强大，根本不存在。
2,DAO分担业务层的逻辑（小逻辑），就如domain层实体里不光是setter,getter的原里一样。但这层逻辑业务仅针对DAO对应的domain层相关逻辑，否则建议到service层。
3,service层应该是主要业务逻辑，不关心应用逻是什么，service的逻辑接口应该永远不了，除非业务改变。个人认为我们的业务主逻辑图都在service层，再配罗dao的小逻辑，（千万不要把hibernate的HQL，或者 相关SQL在这里中写逻辑，初学者误区）。
4,DAO可以认为是大海，有无穷的资源，而service是大海上的船，是dao层上按需所取，船下的海域就是不同dao的小业务逻辑。dao与entity应该是强偶合性的，service以上是松偶合。
5,service不光要dao层，还是分布式，远程访问。就是银行转账的扩展。一般应用都是调用银行接口转账，还有相应的业务关联。转账可能不是一个事务的问题了（当然业务层的设计也可以解决，只是简单举例）

我这里已经很少看到DAO了

怎么出来这么个话题？4的比喻似乎不恰当

DAO直接在数据库进行持久，也可能缓存是内存中，由持久层来决定，因为OO模式，很多实现可能因为one-many,many-one,many-many偶合存在。DAO层不会把所有的从数据库中取出，可能是在内层中，可能是在数据库，顾比喻成大海，而service可能因为业务需，只取一部份资源。

貌似标题和内容都很迷离啊。。。DAO就是对数据访问的封装，仅此而已之多根据需要做一点较小逻辑上的变通或整合而已，为的方便调用者使用比如某些习惯性的流程。要不全是CRUD了。

 

是针对下面这个贴子的

一个简单例子：贫血模型or领域模型

理论上似乎如此，实际上用不着那么复杂……

实际上我的团队，都把HQL把语句都写在SERVICE中了，DAO只是简单的save,delete,find,iterator，搞得dao 太纯，service又有DAO中功能。

DAO就是个鸡肋，起不到什么作用，又好像有一些存在的必要。

如果只是企业应用，只有几个人同时在线在处理的应用，那么DAO就是鸡肋，或者说service直接去了，由DAO担负SERVICE的职责。用spring OpenSessionInView Filter中解决好了。不用去考虑http的io而导致数据库阻塞，或者死锁。一个高性能的web程序，个人认为调用service是异步的，增加超时功能异常功能。web应用只是处理ui的请求，以及业务的委托调用处理。