关于DAO层的疑惑!!!平地一声雷

在讨论的同时。请考虑有关事务的问题。

+1

嗯！一般采用这种脚手架自动生成代码，效率会提高一大截

基本的CRUD容易生成，包括分页查询，复杂条件查询。可以继承公共泛型类或者代码生成的方式。如果用后来的各种一站式框架，这一步也可以省略了。
Dao一般用来屏蔽持久层具体实现技术，jdbc换orm再换webservice等等。当然一般换技术可能性不算太大，但还是真有，我就换过几次。dao封装了数据访问可以复用的各种方法。
service一般可以用来做数据库事务的边界，提高某些业务逻辑的复用性。如果没有事务要求，又没有一点点可复用的可能，我就直接action里面调dao层了。。方便。。见笑了。

以上是个人总结，觉得dao和service还确实有他作用，结构清晰，思路明确。之前就有多人多次质疑Dao，没想到现在还能引起大家的兴趣。

看了很久终于理清了你的问题
第一、为什么不再model层中添加最基本的dao操作方法。原因你已经分析了，当然原因不知这些，model层的潜在含义就是包含属性及状态，但并不包括对自身的操作，它只是一个模型。解决方案你也说了，也就是一个通用的dao层，传递泛型。
第二、怎么样才能让dao层处理更加灵活。比如说是更换了架构，可以几乎不用太多修改dao层，比如由hibernnate框架更换成ibatis,更换了架构不是稍微修改了dao就可以再运行的，如果这样可以的话，那你的程序要么是很小或是只用到hibernnate很小的一部分特性。否则不会出现hibernnate和ibatis两种架构框架，而只是出现版本差异。修改架构的代价很可能就是相关的代码要全部重新添加，而且涉及到复杂的查询（由业务决定），dao层是不可能不变化的。
另外，经验不是看别人代码得来的，而是自己实践加思考得来的。lz的经验论不敢苟同。

把dao层进行封装 get  getList  getPage  save  update  delete 通过泛型，继承做到dao层的通用性，再配上相应的代码生成工具（自己写很简单），基本上dao层不需要写什么代码。

我的做法是
每种实体一个DAO
不在Action或Service层拼HQL，而是在DAO中拼
这样才能做到上层与DAO松耦合（用HQL还是SQL还是其他，是由DAO的实现决定）

DAO 多是CURD  业务都放业务层了,所有都是用泛型接口做通用的DAO

有很复杂的查询，hibernate封装都可以很好的解决吧criteria的各种功能只要封装好点有多复杂应该就可以了，顺便介绍一下我们公司的dao层，
大概一个通用dao，一个jdbctemplate,hibernatetemplate,jdbc操作并不多大部分使用hibernate来完成。CRUD各个操作都有一个接口，比如IAddDao, IQueryDao,IDelDao,IUpdateDao等，还提供一个分页接口，其中分页查询部分使用querydao的查询，代码复用性很高，但是大部分封装的是hql的查询实现。现在新项目尝试用spring的criteria的功能来满足一些复杂的用途。话说criteria如此强大的东西几乎可以满足各种用途了，不过发现使用的人并不多，大多数停留在hql的使用上。

楼主有空研究一下Grails或者Spring Roo吧

与其用自己有限的智慧在这“真正的思考”，还不如学习别人的经验，多看别人的代码。