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层，还是分布式，远程访问。就是银行转账的扩展。一般应用都是调用银行接口转账，还有相应的业务关联。转账可能不是一个事务的问题了（当然业务层的设计也可以解决，只是简单举例）

评论

35 楼 lizhaosuper 2008-12-09  

其实DAO层是应该存在的，DAO层是针对数据库的CRUD的封装起到针对接口编程这样逻辑层就不用关心对数据具体操作的实现只要调用定义好的接口就行，从而实现 业务逻辑层与数据库层的解耦。

34 楼 流浪的面包树 2008-12-09  

说老实话，虽然不喜欢用 但还不得不些！公司的规定

33 楼 soar 2008-12-08  

领域模型中 dao只是接口，也就是现在的repository接口

32 楼 licco1 2008-12-07  

sys53 写道

hudefeifei1 写道

service和Dao层的关系是松耦合的关系，我们一般定义service接口和impl，在service中实现简单的增删改查，不涉及到复杂的 sql语句，或是没有语句，然后在dao层内实现比较复杂的操作，实现serviceIMPL,需要时在servcie中调用dao层中的复杂操作。。，OO不是鸡肋，只是看你如何去用。。。我们也可以合为一层，但那样的话有些时候会有违背开闭原则，对扩展开放，对修改关闭。。。

严重赞同楼上的。
我的此贴反映的就是这个意思。

"service和Dao层的关系是松耦合的关系",支持。不管项目多小，不管底层的表有几张，只要从维护和扩展上考虑，两个层都应该松耦合，只要存在与存储数据交互，就会有这一层。

31 楼 sxhan 2008-12-06  

个人认为与数据库直接接触的东西全部放在DAO层

30 楼 chenzengpeng 2008-12-05  

食之无味弃之可惜的东西···

29 楼 xuyao 2008-12-05  

dao层取不取消要根据项目的复杂度来定

28 楼 xixix2004 2008-12-05  

我觉得“DAO”层的存在是完全有必要，即使是使用领域模型，我们也需要这样一个封装。

我之所以给“DAO”打上个引号的目的在于，“DAO”只是一个称呼，它也可以不叫“DAO”，可以叫“OAD”，“DOA”等等。
现在的问题恰恰就是没有人对于这一层的作用持否定态度，但是很多人却对于这个名字耿耿于怀，然后对于这个叫“DAO”的东西进行批判，进行颠覆。可其实用来取代这个“DAO”的新家伙也还是个DAO，一个不叫“DAO”的DAO。

何必呢，吃饱了撑的。

27 楼 sys53 2008-12-05  

hudefeifei1 写道

service和Dao层的关系是松耦合的关系，我们一般定义service接口和impl，在service中实现简单的增删改查，不涉及到复杂的 sql语句，或是没有语句，然后在dao层内实现比较复杂的操作，实现serviceIMPL,需要时在servcie中调用dao层中的复杂操作。。，OO不是鸡肋，只是看你如何去用。。。我们也可以合为一层，但那样的话有些时候会有违背开闭原则，对扩展开放，对修改关闭。。。

严重赞同楼上的。
我的此贴反映的就是这个意思。

26 楼 hudefeifei1 2008-12-05  

service和Dao层的关系是松耦合的关系，我们一般定义service接口和impl，在service中实现简单的增删改查，不涉及到复杂的 sql语句，或是没有语句，然后在dao层内实现比较复杂的操作，实现serviceIMPL,需要时在servcie中调用dao层中的复杂操作。。，OO不是鸡肋，只是看你如何去用。。。我们也可以合为一层，但那样的话有些时候会有违背开闭原则，对扩展开放，对修改关闭。。。

25 楼 hudefeifei1 2008-12-05  

service和Dao层的关系是松耦合的关系，我们一般定义service接口和impl，在service中实现简单的增删改查，不涉及到复杂的sql语句，或是没有语句，然后在dao层内实现比较复杂的操作，实现serviceIMPL,需要时在servcie中调用dao层中的复杂操作。。，OO不是鸡肋，只是看你如何去用。。。我们也可以合为一层，但那样的话有些时候会有违背开闭原则，对扩展开放，对修改关闭。。。

24 楼 linginfanta 2008-12-05  

存在即合理，我觉得这里不是DAO应不应该存在的问题，而是Service层应不应该存在的问题，项目小，业务逻辑简单，service里啥都没有干，就调了一下dao，那就可以把service省去，action里直接dao了。

23 楼 cuisk0328 2008-12-04  

Dao 层面上还是需要存在的，现在很多人写代码已经是 bo层就已经写好了很多dao的东西，我觉得这毕竟是业务层面的东西，如果项目很大，管理起来不是很好,维护也很困难。

22 楼 yangwn 2008-12-04  

sdh5724 写道

看表的多少吧， 超过50张， 还是用吧。 艾， 每个人从事系统的大小不一样， 系统需要维护的程度不同， 总是想法不一样的。 正所谓的屁股决定脑袋！

楼上的说的很对！
在屁股大得坐不下马桶的同时，脑袋一定要清楚的知道屁股真的做不下！

21 楼 sdh5724 2008-12-04  

看表的多少吧， 超过50张， 还是用吧。 艾， 每个人从事系统的大小不一样， 系统需要维护的程度不同， 总是想法不一样的。 正所谓的屁股决定脑袋！

20 楼 sys53 2008-12-04  

个人总结：
如果只是简单数据crud操作，没有更复杂的dao，也没有其它大并发量等原因的考虑，系统差不多只解决替换数据库管理系统而已，那么可以考虑把service取消，让dao来进行这么简单业务的计算。否则，业务计算都在service层（业务逻程层）尽量保证这层相对比较溥，绝对不要把HQL,SQL,或者第三方持久框架的特性写到service层了，同时service中还有事务脚本的作用。

现在的系统应该不太可能有简单到只是替换数据库管理系统，除非是一些系统的配置。
如果只是这些配置，都可以考虑把dao直接让jsp应该调用，直接把Hql之类的代码在jsp中去，让开发更简洁。前提就是真得不会有简单逻程，只是展现数据库数据。（就算是这样，个人也不推荐这种模式）

19 楼 风花雪月饼 2008-12-04  

theiiidoor 写道

sys53 写道

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

可以考虑把DAO统一起来，变成一个～

事实证明这样做是错的。
统一为一个？那你的SQL都写到Service里去了。

18 楼 yangwn 2008-12-03  

我不认识DAO是一个鸡肋，在封装持久化部分起到了决定性的作用；
而且在DAO还可以重用，只要接口做的足够明确。
目前的系统还没有发展到将所有的数据放到内容机中。
目前企业级系统还是以关系数据库为基准。

17 楼 meatloaf 2008-12-03  

道不行,乘桴浮于海

16 楼 airsise 2008-12-03  

meconsea 写道

所以DAO只是N Layer 架构初期的一种设计理念！如果从技术角度去实现和变通的话，可以不存在。但是理念一定要清楚，就跟SOA一样，他就是一个设计理念。

说的很对。

DAO层对于系统的业务来说，没起什么作用。业务他并不关心数据是存放在文本里，还是数据库里。
所以DAO层，只是一个工具而以。我可以叫他DAO,我也可以叫他StoreTools。

如果硬加抬扛，说没有技术支持，业务用什么实现。我就没话好讲了。。。