Question

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

一个例子可能会有用：

假设我有一个类，它将封装我的应用程序的一些连接信息。称之为'ConnectionInfo'

class ConnectionInfo
{
    // ...
}

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

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容器）？

Answer 1

我不认为类设计存在问题

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

实际上有两种情况。

1-你的ConnectionInfo和Worker是Singletons：在这种情况下，如果你创建一个AnotherClass的对象而不是ConnectionInfo的相同对象，那么Worker将由AnotherClass共享。

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

但是对于ConnectionInfo，我可能会说它可能是一个Sigleton对象，因为它是你的应用程序需要的常见信息所以我会说ConectionInfo为Singleton并且休息很好，我认为你没有违反任何IoC规则。

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

1 个答案: