是否可以说，当你到了将一个 DAO 注入另一个 DAO 的地步时，你已经超越了 DAO 的范围，并达到了业务层的问题？
注意：我并没有考虑特定的问题，只是试图提取关于使用 DAO 的一般经验法则。
【问题讨论】：
标签： java spring design-patterns architecture dao
DAO 和 Business 之间的划分是“任意的”。当一个类用于“从存储库中检索和存储数据”时，我们说它是一个 DAO。您在另一个 DAO 中注入 DAO 的事实并不能阻止它“从存储库中检索和存储数据”，所以对我来说，您的问题的答案是否定的。
没有任何地方说你不能将一个 DAO 注入另一个 DAO（即使通常不会这样做）。
【讨论】：
是的。 DAO 不应相互依赖。
协调不同的 DAO 是业务/服务层的工作。
但是，如果您描述您的具体情况，我们将能够给出更准确的答案。
编辑：
阅读@edutesoy 的回答后，我看到了他论证中的逻辑。
所以我会通过说来完善我的答案 - 这样做并不是固有错误，但它有点“臭”。
这是因为 DAO 层的正常结构 - 通常每种类型的实体都有一个 DAO (CustomerDAO, OrdersDAOetc)。如果您的 CustomerDAO 正在使用您的 PaymentsDAO，这闻起来有点像违反 SRP：CustomerDAO 是否也负责与付款相关的操作？
所以，总而言之——在将它引入我的代码之前，我肯定需要一个很好的理由。
【讨论】：
您应该从思考什么是 DAO 开始。
如果你使用 JPA，那么实体管理器已经是一个通用的 DAO（通过 DAO 模式）。大多数 Java EE 开发人员所说的 DAO 并不是 DAO 模式的 DAO。这是某种重构：将与数据库相关的语句移到外部类中（我认为这就是您所说的那种 DAO）不要误会，我认为这很有用。 em>
所以我对这个 DAO 的理解是一些重构的东西。重构的总体目标是使代码更具可读性、可维护性。因此，如果您的代码通过这种间接方式变得更好，那么继续，但您应该记录您的项目 DAO 模式与可能其他 Java EE 开发人员使用的 DAO 模式略有不同。
【讨论】：