Java 从另一个DAO工厂调用一个DAO

目前，我的应用程序体系结构如下：

看法→ 节目主持人→ 某个异步执行器→ 道场→ DAO（接口）→ DAO（Impl）

就目前而言，这种建筑是可行的；主要是因为我现在只需要一种刀。但是随着需求的增长，我需要扩展到多个DAO，每个DAO都有自己的数据获取实现

下面是我的例子：

最头痛的问题来自

FooCloudDao

，它从API加载数据。这个API需要某种身份验证方法—一个在登录期间存储的字符串令牌（比如，一个

会话
对象—是的，它也有自己的DAO）

通过
FooDaoFactory
传递一个
会话
实例是很有诱惑力的，以防没有连接，但这似乎有点骇人听闻，违反直觉。我可以想象的下一件事是从
FooDaoFactory
中访问
SessionDAOFactory
，以获得
会话的实例（然后在需要
FooCloudDAO
实例时传递该实例）

但是正如我所说的，我不确定我是否可以做这样的事情——也许我可以，但这真的是正确的方法吗？
我想你的问题实际上是
FooCloudDao
与其他组件有不同的“依赖性”，并且您希望避免在途中通过每个类传递依赖项

尽管有很多设计模式可以解决您的问题，但我还是建议您看看依赖注入/控制反转原则和框架。您要做的是：

您将为您的
FooCloudDao
需要创建一个接口，例如：

您将创建并实现该接口，该接口将从会话或该东西来自的任何地方获得：

上面定义的类需要注册到您选择的IoC容器，作为
APITokeProvider的实现
接口（这样无论谁请求
apitonkprovider
都将被解耦
从实际实现->容器将给他
适当执行）

在
FooCloudDao类上有一个名为构造函数注入的东西（容器稍后使用它来“注入”
您的依赖关系）：

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

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


FooDaoFactory
保持依赖项通过
您使您的代码更易于测试，因为您可以在没有真正会话的情况下测试
FooCloudDao
（您只能给出伪接口实现）
以及控制反转带来的所有其他好处

会话注意事项：如果您在
SessionBasedApiTokenProvider
中遇到获取会话的问题，大部分时间会话本身也会向IoC控制器注册，并在需要时注入。
我非常喜欢您解释问题的方式。话虽如此，你的问题是它是否合乎道德？这似乎不属于堆栈溢出的范围，因为它使问题变得基于观点。好吧，我可以重新表述这个问题-这是正确的方法吗？如果这也被认为是基于观点的，我就被卡住了。再说一遍，任何答案都必须包含作者的观点。也许这更适合程序员。stackexchange.com？我不介意将问题转移到程序员身上。如果大多数人认为有必要这样做的话。然而，有相当多的问题与此类似，在SO中得到了提问和回答。还有，举几个例子。作为一个程序员.SE用户，这似乎是我们网站的一个好问题，所以如果这里有任何高代表性的用户觉得这与主题无关，那么就继续投票支持迁移。或者在这里回答，两者都可以。很好的解决方案！事实上，我以前使用过DI（Dagger），但由于它倾向于使用样板代码，所以决定放弃它。但我想，当谈论依赖优化时，这真的是一种方式。谢谢你的洞察力！
interface ApiTokenProvider {
     string GetToken();
 }

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

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