关于Dao设计的典型问题

是应该放在service层中，dao层应该提供系统的原子数据库操作，而与查询有关的操作只需要接受service层传递过来的sql语句，而service负责解释role，或者request中的参数，并且组合，进而形成dao层可以使用的sql语句。这样若是你更改持久层时间，只需要在service层增加相应的类去实现相应的解析即可（role，request->特定的sql（标准sql/hsql））

我看过很多关于service+dao模式的文章，不少都讨论这个问题。
一般来说，dao是跟数据库的表一一对应的，但当一个操作涉及跨表（例如联合查询），那怎么办？
我个人是这样认为的，首先是抽象一个DaoBase，封装好基本的crud操作，然后每个dao集成这个DaoBase，如果关于一些跨表查询的操作（例如A联合B表查询），那就在根据需要，写在A或者B的DAO里。
然后在Service统一封装。

以前做软件都是随便写几个Service,纯粹为了Service而Service,当某天突然发现我的两个Service竟然需要互相访问,于是乎开始考虑如何设计Service,特别是Service之间的依赖关系如何设计的问题!我把Service之间的依赖关系看成Service层设计的重点,不知道大家怎么看?

在dao和service之间在多加一层，因为dao的每一个文件是和数据库的表一一对应的，因此中间的这一层不单对dao进行封装，同时也处理多表之间的关系（如联合查询等），最后service再对这一层进行封装。这样虽然会增加一点工作量，但能使业务逻辑和数据访问很好地分开。

同级别的类或包之前需要相互访问，表明其中有一些逻辑可以分离出来放入下层，或者单独做成一个层。

联级查询，直接使用SQL不但简洁，而且效率很高。如果是调用DAO来实现，可能会得不偿失！

大家都在胡说八道!

可不可以这样：Dao层只负责解决与DB的交互，Service层负责组织需要的Dao。因此，Dao设计的时候应该针对数据库结构、表结构，不再考虑业务逻辑。Service设计的时候针对业务逻辑，考虑对应的Dao。

......无语......怎么....变成了...为设计而设计???
你们的需求去哪里了?

我同意18楼的意见我也觉得dao只是实现对数据库中单个表的添删更新查询的操作。而如何实现对表的查询则放在service层