如何设计DAO层

1.粒度非常细,那和直接在service里写sql有什么区别?不知道你说的细到什么程度.比如要更新某个状态字段,也在DAO写一个专门的方法?或者为每种关联查询写方法?
3.我的理解中,这已经不能简单叫做DAO了.个人认为DAO应该是直接用代码生成器搞出来的东西

楼上的应该比较熟悉hibernate，一定也在用它开发吧！
做项目追求速度，而对于业务较复杂的（一次性关联4，5张表），你不写SQL，让H去持久，可能问题会比较多！且开发测试效率反而降低！
我说的粒度细，是指一个DAO方法里只处理一次数据库访问，分页也该分成2个DAO方法！
另外根据业务去处理，如你所说更新一个状态字段，如果业务需要，且这样设计是可行的，那么就这么做！有什么不对吗?有些场景就是这么做的!

你说service层写sql,那么你根本就没有把整个层次分清楚！如果感觉DAO层简单，那是因为框架强大了，如果什么链接释放，事务提交都让DAO来做，这样就算是DAO层了？

你说DAO应该是代码生成器搞出来的，那么就是业务层只要操作下对象，SQL配置下，直接就持久了？你认为此类频繁的操作，放业务层合适?DAO最大的理念就是分离业务逻辑与持久代码！

楼上的,我就不明白,DAO就是在单表与类间架起一座桥梁,它功能本来就有点不伦不类,往上往下都是孤立的东西,无法独立运用,为什么不能用Service取代?

在eclipse里自动生成的DAO比较罗嗦，是不是一般都不用自动生成的DAO，而是自己写的啊？？？

你说往上往下孤立？你直接WEB层调用DAO也可以啊，只是这样的系统出来，非常糟糕罢了！

用service取代这个说法，我认为其实有道理，但是DAO层的理念-分离业务代码！这点来得更实际！
持久代码很单一，这点你赞同吧！业务代码比较灵活！
业务代码与持久代码放一起了，就是在混乱你的视线！难道这样的问题存在，还不需要独立一层DAO？哪怕才几行，但是，你的代码从应用上讲，完美！

另外，用hibernate的也有DAO层吧，它都已经完全侵入DAO层了，还提倡单独写DAO！
楼上的自动生成DAO，应该算是最简单的CRUD操作！肯定不会是最终的，节省部分重复代码罢了！

没说Service要同时包含业务代码与持久代码,它应该分成两部分,持久交互部分和业务部分,或者叫Service和Logic两层.

不同意DAO是因为它功能太单一,单表和类的桥梁而已,而现实中非CRUD的运用很多,这么做DAO不是显得鸡肋吗?还不如用Service和logic俩取代它.

取代的方法值得斟酌,但DAO层我还是觉得应该消除.

几个数据库表？关键的问题不说清楚

我只是举一例子，设计一个DAO层和有几张表有关吗？表多就设计的复杂点，表少就设计简单点？？？？

换种说法吧,除了CRUD外,大家觉得关联查询,分类汇总等代码应该放在那一层.DAO?Service?Logic?

看了那么多回复，现在我对dao的认识：dao它是封装对数据库操作的所有方法，这里面是不应该包含业务。它也就是业务层和数据层的中间层。它可以放到数据层中，但不能归类到业务层。
比如你要关联查询，你在业务层做好关联查询的条件，在把条件給DAO层，它就查处数据库中所有符合这些条件的记录，在返回记录（或记录对象等）。
就象自动售货机：你給它了3块钱+你选择的是雪碧,那么它就给你雪碧了，它不管你的钱是哪里来的（偷来的，抢来的）这里就是靠业务层做了，它也不管你拿了雪碧后是喝掉还是扔掉。这些它都不管，它只管你给他什么样的条件，它返回什么样的结果。
不知这样认识是否正确。