从另一个 DAOFactory 调用一个 DAO

Question

目前，我的应用架构流程如下：

View → Presenter → Some asynchronous executor → DAOFactory → DAO (interface) → DAO (Impl)

目前，这种架构是可行的；主要是因为我目前只需要一种 DAO。但随着需求的增长，我需要扩展到多个 DAO，每个 DAO 都有自己的关于如何获取数据的实现。

这是我的例子：

主要的麻烦来自FooCloudDao，它从 API 加载数据。此 API 需要某种身份验证方法 - 在登录期间存储的字符串令牌（例如，Session 对象 - 是的，这也有自己的 DAO）。

通过FooDaoFactory 传递一个Session 实例是很有诱惑力的，以防万一没有连接，但它看起来很老套且违反直觉。我可以想象的下一件事是从FooDaoFactory 中访问SessionDAOFactory 以获得Session 的实例（然后在我需要FooCloudDAO 实例时传递它）。

但正如我所说，我不确定我是否可以做这样的事情 - 好吧，也许我可以，但真的是这样正确的做法？

Answer 1

我认为您的问题实际上是 FooCloudDao 与其他组件具有不同的“依赖项”，并且您希望避免在途中通过每个类传递依赖项。

尽管有相当多的设计模式可以解决您的问题，但我建议您了解一下依赖注入/控制反转原则和框架。你会做的是：

1. 您可以为FooCloudDao 的需要创建一个界面，例如：

interface ApiTokenProvider {
     string GetToken();
 }

1. 您将创建并实现该接口，该接口将从会话或从任何地方获取它：

class SessionBasedApiTokenPrivider implements ApiTokenProvider {
    public string GetToken() {
        // get it from the session here
    }
}

1. 上面定义的类需要在您选择的 IoC 容器中注册作为ApiTokenProvider 的实现 接口（以便任何人要求ApiTokenProvider 将被解耦 从实际实现中->容器会给他 正确实施）。

2. 你会在你的FooCloudDao 类上有一个叫做 constructor injection 的东西（这后来被容器用来“注入” 你的依赖）：

public FooCloudDao(ApiTokenProvider tokenProvider) {
    // store the provider so that the class can use it later where needed
}

5. 您的 FooDaoFactory 将使用 IoC 容器来解析 FooCloudDao 及其所有依赖项（因此您不会 用new 实例化FooCloudDao)

---

执行这些步骤时，您将确保：

• FooDaoFactory 没有传递依赖项
• 您可以使您的代码更加可测试，因为您可以在没有真正会话的情况下测试您的FooCloudDao（您只能提供假接口实现）
• 以及控制反转带来的所有其他好处...

关于session的注意事项：如果遇到SessionBasedApiTokenProvider中获取session的问题，大部分时候session本身也是注册到IoC控制器，在需要的地方注入。