处理与 DI / IoC 的关系和潜在的不一致答案

【问题标题】：Dealing with relationships and potential inconsistencies with DI / IoC处理与 DI / IoC 的关系和潜在的不一致
【发布时间】：2010-08-13 07:44:46
【问题描述】：

我在设计类以最好地利用 DI / IoC 原则时遇到了麻烦，特别是当一个类与其依赖项之一共享依赖项时（即 X 具有依赖关系 Y 和 Z，而 Y 具有依赖关系 Z）。

一个例子可能会有用：

假设我有一个类可以为我的应用封装一些连接信息。称之为“连接信息”

class ConnectionInfo
{
    // ...
}

我设计了一个使用连接信息的工作类，因此我将通过构造函数注入我的依赖项。

class Worker 
{
    public Worker(ConnectionInfo c) 
    {
        // ...
    }
}

现在，假设我想构建另一个类。它需要访问连接信息，但我也想访问 Worker 类提供的功能。

class AnotherClass
{
    public AnotherClass(ConnectionInfo c, Worker w)
    {
       // ...
    }
}

这一切都很好。但是，注入到 Worker 中的 ConnectionInfo 对象和注入到 AnotherClass 中的 ConnectionInfo 对象之间存在隐含的逻辑关系。只有当它们相同时，设计才有意义。不过，这不是强制执行的。没有什么能阻止一个 ConnectionInfo 被注入到 AnotherClass 中，一个完全不相关的 ConnectionInfo 被注入到 Worker 中。

我是否以错误的方式处理 IoC / DI？
类应该以不同的方式设计，还是应该以其他方式处理问题（例如通过参数验证强制执行，或者只是将其留给 IoC 容器）？

【问题讨论】：

标签： dependency-injection inversion-of-control

【解决方案1】：

我不认为Class设计有问题

当您的客户端代码需要 AnotherClass 的对象时，它将创建自己的 ConnectonInfo 和 Worker 依赖项。

实际上有两种情况。

1- 你的 ConnectionInfo 和 Worker 是单例吗：在这种情况下，如果你创建了 AnotherClass 的对象，那么 ConnectionInfo 和 Worker 的相同对象将由 AnotherClass 共享。

2- 如果第 1 点不正确：每次创建 AnotehrClass 时，Container 都会将依赖项作为新对象注入。

但是对于 ConnectionInfo ，我可能会说它可能是一个 Sigleton 对象，因为它是您的应用程序需要的公共信息，所以我会说将 ConectionInfo 设置为 Singleton 并休息很好，我认为您没有违反任何国际奥委会规则。

【讨论】：