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