java - Service 和 DAO 之间的关系应该是一对一还是一对多？

Question

引发这个问题的代码是我公司代码库中的一个服务，其中包含四个不同的 DAO。直到我看到这个服务已经与属于一个完全不同的服务的方法混为一谈，我才想太多。在这个 Service 中创建这些无根据的方法的原因仅仅是因为所需的 DAO 是这个 Service 类的私有(private)成员。

这是开发人员的不当行为，还是在大多数情况下每个服务类拥有多个 DAO 是错误的？

注意:我注意到每个服务类拥有多个 DAO 似乎是合理的，只要它们都包含在同一个数据库中。但是拥有来自多个数据库的 DAO 似乎可能会导致问题。

Answer 1

我认为每个服务类有多个 DAO 没有错。多年前我第一次开始做 Web 开发时，我有一个服务一个 DAO，因为这似乎是最合乎逻辑和最直接的方法。然后，我开始看到提供不同服务的 DAO 之间存在类似 API 的问题。因此，我的“不成熟”解决方案是将这些通用 API 推广到某些父 DAO 以由这些 DAO 继承。随着项目的发展，它已经到了继承不再有意义的地步，因为我遇到了 80% 的子 DAO 需要该 API，但 20% 不需要，但它们仍然从同一个父级继承的情况DAO，因为它们共享其他类似的 API。你看到这里的问题了吗？我的意思是，在 Java 中，你只能从一个父级继承，所以我最终在父级 DAO 中填充了“可能”被“大多数”DAO 使用的 API，这首先完全违反了继承原则。

现在，我所有的 DAO 类都有特定的职责/任务。一个 DAO 可以调用另一个 DAO(例如，大多数 DAO 使用 LoggingDAO 来记录用户操作)。通过这种方式，DAO 不再提供一个服务于特定服务的 DAO，而是提供了可能使该服务受益的操作列表。服务将“使用”任何 DAO 来完成任务。

希望这个解释有所帮助。