通常,我尝试以这样一种方式构建我的DAO类,使它们完全依赖于自己。它们可以与多个表交互,但前提是数据与基础对象相关。例如,假设我有一个约会对象,约会DAO从约会表中提取数据。如果约会表是服务ID,则可以说是一列,该服务ID是将约会绑定到服务的外键。服务表完全独立于约会,并且具有自己的DAO,用户可以在其中添加或删除服务。
约会对象具有服务字段,用于存储服务对象。我这样做是因为在视图的许多情况下,在处理约会时必须引用此服务对象。
在约会DAO中,我可以编写单独的SQL语句来从其表中提取服务数据,并在约会DAO中重新映射所有这些,但所有这些都已在服务DAO中完成,并且就像调用一样简单serviceDao.find(服务Id)。我觉得在我的约会DAO中引用服务DAO有点脏。这是因为我有设计问题还是可以做这种事情?我试过研究这个问题,结果是50/50。
答案 0 :(得分:2)
为什么让一个服务DAO引用另一个服务如此糟糕?
您需要关注的一个问题是延迟造成的死亡。如果您的服务DAO带回N个实例,然后您循环这些结果以带回其他内容,那么您将有N + 1个查询 - 以及N + 1个网络往返 - 其中一个带有一个JOIN的往返将带来所有这些数据立即回来。
我建议你不要担心DAO,而是更多关于编写最好,最有效的SQL。
答案 1 :(得分:1)
我不确定是否存在特定的“标准”,但我通常在商业意义上而不是实体中组织我的DAO。因此,如果约会和服务通常以某种形式相关,我可能最终将它们放在一起。也许像AppointmentServicesDAO(如果这是一个合适的名字)。使每个实体的对象更适合模型而不是DAO。
我同意你的看法,感觉很脏。我通常不喜欢在DAO中调用其他DAO。如果确实需要在类中进行某种分离,那么可能会有一些基本的继承。
但是,我还没有研究标准硬核。主要来自经验,所以如果有人有更好的建议,就会喜欢听到它们。
答案 2 :(得分:0)
我仅通过id引用属于其他DAO的对象(在您的示例中为“service”id),并使用对象缓存来清晰地分隔两种类型的对象。