关于DAO和Service

看到有很多人在讨论这个问题，我了解的也不深，瞎说一下。

我认为DAO的功能就像他的名字就是提供数据访问。为什么要这么做呢（这里是设问，绝没有反驳DAO的意思，下面要说利用DAO的好处）？因为你现在用的可能是hibernate，可能对每一个数据访问都使用save之类的方法来取得PO，但是有一天你的BOSS告诉你这个hibernate不好时（个人很喜欢），你不得不换另外一个持久化层，或是另外的数据访问层，这个时候你完全可以另外实现一套接口，而不改变原来的任何东西。但你实现另外的一套时，你发现你错了，这两个完全不同的框架写出来的代码却有很多一样的，为什么？因为你把太多的本该写道Service的业务逻辑判断也写到这里面来了，大量的if，简直就是浪费你的时间，你很后悔为什么当初把根数据访问毫不相干的逻辑判断也加进来了。这就是你的Service把DAO入侵带来的坏处，当然有很多人做着相反的事，把HQL带到了Service里面，同样想一想，你的hibernate变了，哪里还有什么HQL，你要改变不仅仅是DAO，而且还要改变Service里面本该由DAO执行的东西。要是全是你做的时候你可能还能应付，要是你的同事做的Service，你还要红着脸跟他说“大哥，今天我请客，帮忙改一下吧，哈哈”。

我就是把好处和坏处说出来，当然可能因为特殊的项目，特殊的环境，特殊的开发团队和特殊的开发周期要求你只能怎么方便怎么做，那完全可以随便，直到不报错什么都是好的，但是这种方便是建立在以后的痛苦之上的。

小弟拙言，上面的人物纯属虚构，绝对不涉及到任何人。

所以我的看法是，要想知道你的设计是否合理，就是这想一下，要是有一天这个层全都变了，设计上是否方便，对其他层的入侵大不大。

你要是确定不变，你就想怎么做怎么做，当然就像我跟一个网友说的一样：“这绝不会是一个好的系统，更不会是一个能赚钱的系统。”

楼主说的不错，分层设计就是要分清职责，让变化影响到的范围尽可能的小

To 差沙:
   你的举例和总结,很不错,可是每个人的理解程度有高低,使用有好坏.所以我希望的是大家尤其那些对此有不错造诣之士,能够多多举例和总结,帮助那些不熟悉的更好理解,同时也希望能够总结出类似模式一样的东东,这样会不会更好一些呢.

谢谢楼上各位的支持，我也会尽自己的能力解答大家在实际开发中遇到的实际问题的。

恕我冒昧，我没有看懂楼主的意思，究竟是想批驳DAO还是强调DAO与Service的区别呢？
   楼主谈到一个逻辑的重复的问题，这就首先要考量DAO中的逻辑和Service的逻辑是个怎么样的概念和区别了。DAO的本身职责是将数据对象持久化，那么在解构的过程中，自然会有很多相同的代码（比如说用hibernate也好，ibatis也好，或者其他的也好），这里的代码重复如果楼主把它理解成是将Service中的逻辑侵入到DAO中的话，就不对了。Service中的逻辑准确地讲是业务逻辑，或者说属于系统级的逻辑，并不只是结果数据对象的持久化解构和处理

不好意思，可能是我第一个设问让大家引起了误会，我绝对没有批驳DAO的意思，而是一直在强调DAO与Service的区别，第一个是设问，目的是想引出下文，大家可不要加上感情色彩呀，寒~~~~~中国语言博大精深，没说好就理解错了。

至于第二点，确实我忘了强调要区分各种逻辑操作，感谢楼上补充。