我对service和DAO关系(业务和存储逻辑的关系)理解不足,希望指点

查询时候要把DAO里面的业务逻辑剥得多干净呢?

比如关联查询可以解决的问题,是直接在DAO里面关联查询,
还是应该先取出一组对象在service里进行逻辑判断,再根据逻辑判断结果来进行第二次查询呢?
先取一个对象出来判断,这样判断的逻辑可以放到service里面,DAO不需要添加很多的方法,
但是需要多次查询,会慢不少吧;
如果直接关联查询,算不算业务逻辑影响了DAO呢;

比如我先搜索出年龄<30的老师,然后搜索每个老师的学生成绩?
还是说可以联合查询,直接搜索这些老师的学生成绩?
后一种只执行一个SQL,速度会快很多,但是感觉DAO的方法和业务有了相关性?

没有人解答一下吗?我的表达能力可能有点问题(汗)
我说得清楚一点:
比如StudentService要提供一个方法,选择符合某条件的老师的学生的成绩.
一个方法,可以先调用TeacherService的方法获取Teacher的集合(应该用TeacherService还是TeacherDao?),
再根据各teacher的id值调用StudentDao的方法取学生的成绩;
另一个方法,这时候也可以直接联合查询,让StudentDao直接提供一个方法取学生的成绩;
这样的情况怎么做才是对的?

单一业务逻辑，可以放到service层，单独做！不需要放到域对象里！
跟域对象紧密相连的，放里面是理所当然！

域对象里调用DAO是错误的！

回:galaxystar 

你说得对,domain object不能使用DAO,该在service或者manager里面,我说错了(请允许我修改原贴)
不过其实我是想问一下,DAO里面的业务逻辑要剥离得非常干净
干净到联合查询都应该分开查询吗?

如果将联合查询看成是一个独立的任务,DAO里面的业务逻辑要剥离得非常干净并不需要将一个独立的任务分成两个吧.不过若在程序里面需要非常细粒度的操作,你需要年龄小于30的老师,又需要这些老师下面学生的成绩,那么就需要将联合查询拆分了,个人认为这方面的问题需要灵活处理.

如果是超大数据量的查询操作,将联合查询分开来做查询所带来的性能上的开销将是个恶梦...

个人认为应该具体问题具体分析；很多工作交给数据库直接处理还是比较好的选择，如果把数据库操作每一部分都分离开，性能上肯定会受到影响；再说了这样作的话hibernate等的多表查询和级联查询就没有什么意义了！

典型为了OO而OO的反面教材

感觉SERVICE层就是对DAO层进行一个再包装,
对于你的业务逻辑判断当然是放在调用层啦,谁调用...谁判断...
现在是流行把与DATA层紧密联系的业务放到PO层里面,做为一个DOMAIN OBJECT.

这个问题我猜每个dao的使用者都会遇到。不知有哪个有好的解决方法

DAO本来就是知道DomainObject的,要不它如何返回DomainObject呢？
再有，hql放在那里不就是让你用的麽？
DAO里面进行多对象连接，再正常不过了，没啥好顾虑的。