DAO层当前还应该继续存在

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

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

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

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

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

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

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

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

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

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

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

何必呢，吃饱了撑的。

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