dependency-injection - 将依赖项传递给 "right way"

Question

在将依赖项注入(inject)构造函数时，我不太确定如果执行以下操作是否会破坏 SOLID:

public MyClass(IConfiguration configuration)
{
    _port = configuration.GetValue("Port");
}

而不是像这样传递纯值:

public MyClass(int port)
{
    _port = port;
}

第一个似乎是某种服务定位器。

这里的问题是:是否可以传递复杂的依赖项只是为了检索类实际依赖的单个值？

对我来说它看起来并没有那么错，但是它不必要地隐藏了真正的依赖关系，这可以更容易地通过。

Answer 1

从 SOLID 原则的角度来看，我没有看到明显的违反:

• 单一职责:无论您是否注入(inject)端口或 IConfiguration 都不会改变 MyClass 的职责数量。
• 开放/封闭:这个原则是关于防止彻底改变。与注入(inject) IConfiguration 相比，我看不出注入(inject)端口如何防止彻底改变。
• Liskov Substitution:这个原则是关于让衍生品表现得像它们的基类规范。注入(inject) IConfiguration 对 LSP 没有影响。
• 接口(interface)隔离:此原则插入使用窄接口(interface)。这有点棘手，可能需要更仔细地检查代码以查看 IConfiguration 是否很宽并且违反了 ISP。但是，仅从这段代码来看，我会说不存在 ISP 问题。
• 依赖倒置:该原则指出我们应该针对抽象进行编程，而且 - 几乎同样重要的是 - 它指出客户端应该拥有 抽象。如果 IConfiguration 是框架定义的抽象，我们可能会认为此代码违反了 DIP。但是移除所有对框架抽象的依赖并不总是可能或可行的，所以我们应该务实。在您的情况下，不可能说依赖 IConfiguration 是否实用。

但是，除了 SOLID 原则之外，还有其他指南可能对我们有所帮助:

• 注入(inject)构造函数的主体应该很简单:当涉及到 DI 时，规则是 an Injection Constructor should do no more than receiving the dependencies .它不应该使用它。但是，MyClass 构造函数在构造函数内部使用了 IConfiguration。
• 注入(inject)构造函数的定义应该是最小的:注入(inject)构造函数应该只提供它运行所需的依赖项。它是一种面向构造函数的 ISP，与 Nikola’s 4th law of IoC 相关。 .在这种情况下，您将提供一个具有广泛功能的接口(interface) (IConfiguration)。在您的问题中，您在这方面指的是服务定位器反模式。虽然注入(inject)IConfiguration当然不能算是Service Locator，但是从加载配置值来看，IConfiguration是类似的能力。最好缩小范围并尽可能明确，int port 与 IConfiguration 相比要明确得多。

所有这些都准备就绪后，让我尝试回答您的问题:

Is it okay to pass complex dependencies just to retrieve a single value the class actually relies on?

考虑到上面关于 DI 的指导，我会说注入(inject) int port 或包装 int port 的类型化配置类更好，这是特定的到 MyClass；例如MyClassSettings:

public MyClass(MyClassSettings settings)
{
    _settings = settings;
}

两者都传达相同数量的信息，但后者不那么模糊，因为 int 可以表示任何内容，而 MyClassSettings 非常精确并且很容易从 DI 容器中解析.