数据库的表关联是在dao层做好，还是在业务层做好？

我现在参加的一个项目，是通过jdbc存取数据库的。技术主管认为表结构的关联应该是在业务层来做，而dao只是对一张表进行操作。不知道这样的设计有什么好处和什么不足？

业务层只有对象关系，哪来的表？

你说的表结构的关联是不是指逻辑上的关联，比如一个商业逻辑需要操作多张表，如果是的话，这块当然要放到业务层。
一般我们的设计中都是一个DAO对应一张表，这样结构清晰，你可以看看J2EE的DAO模式。

"你说的表结构的关联是不是指逻辑上的关联，比如一个商业逻辑需要操作多张表，如果是的话，这块当然要放到业务层。 一般我们的设计中都是一个DAO对应一张表，这样结构清晰，你可以看看J2EE的DAO模式"

我现在的开发就是用这种方式，但关键是如果一张表和多张表有关联，那样的话读取一次数据不就要和数据库多次的连接。数据量大的时候效率会不会有问题呢？

静态表关联在DAO层做，业务上的动态表关联在业务层做，但是JDBC的开发恐怕很难做到这点....

我也有类似得疑惑，现在做得项目，在查询得部分，大多都是四五个表得复杂关联查询，很无奈！

sql得话，维护起来，很费劲。

也程序做OR映射得方式，性能上又差得太多，明显得反映迟钝，能够缓存得东西都不多（或许是我写得OR映射得水平还不够吧）。

总之，现在是进退为难，郁闷中。

楼主，你们leader的建议是对的，所谓在业务层的关联其实只是逻辑的关联，真正的关联查询还是定义在dao的。

业务层只是根据业务,调用不同的DAO的操作
这样做

public class UserBusiness{

final UserDAO  userDao; //接口
final DealDAO dealDao;  //接口

public void UserBusiness(UserDAO  userDao,DealDAO dealDao){
this.userDao = userDao;
this.dealDao = dealDao;
}

void XXXMethod(){
userDAO.doMethod();
dealDAO.doMethod();
}
}

事务控制也在这一层,business层上还有一个Factory,用来实例化Business,
具体化DAO的实现...

^_^ 恩,到业务层就可以了...

我们采用Spring 把他们组装起来...

  
       DAO原本是为了封装存取的，如果把存取代码放到业务层就违背了初意，

这问题我也一直思考。http://www.erproad.org/showlog.asp?cat_id=30&log_id=370

      IMO，在底层存取上绝对的边界是没有的，理论上谈谈还是可以，但实现起来不现实。 

    除非你脱离对象关系，仅仅用业务字段维护关系，绝大多数情况下，这都是不可取的。如果真正做到存取代码和业务逻辑分离，必然出现跨实体操作的DAO.

     从效率上来说也如是，如果把一些关系数据库特性抛开不用，那代码的效率可想而知。

     我的想法是，不要太拘泥与理论上的一些概念。