dependency-injection - IOC 容器类型解析和注入(inject)位置

Question

在域模型的边缘解析和注入(inject)具体类型然后让这些类型通过域下降是最佳实践吗？例如，让容器将具体类型注入(inject) Web 应用程序中的 MVC Controller 构造函数，或基于服务的应用程序中的服务端点？

我对容器对象图连线的理解有点复杂。

在域中执行相当于 Container.Resolve() 的操作是否合适？

Answer 1

DI 实际上只是达到目的的一种手段:松耦合 .这是一种通过将接口(interface)(或基类)注入(inject)消费者来实现松散耦合的方法，这样您就可以相互独立地改变两者。

作为一般规则，注入(inject)具体类型 并没有什么收获.您不能将类型与另一种类型交换，因此失去了 DI 的主要优势。

您可能会争辩说，这意味着您也可以从消费者内部创建具体实例，但更好的选择是 提取接口(interface)从这些类型中(然后注入(inject)它们)。

不:它是 永远不合适从域模型中的容器中提取。那是Service Locator anti-pattern . 好莱坞原则 在这里也适用:

Don't call the container; it'll call you

(也就是说，即使使用具体类型，注入(inject)它也有一些次要好处。如果它是非密封的并且有一个或多个虚拟成员，你仍然可以覆盖它的一些行为，即使它是密封的，你仍然会得到如果你注入(inject)它来控制它的生命周期 - 例如，你可以在多个消费者之间共享同一个实例。然而，这些好处纯粹是次要的，通常不是我们决定注入(inject)任何东西的主要原因。)

另一个问题(您似乎实际上要问的问题)是注入(inject)服务只是为了将它们传递给其他服务是否合适。不，不是，因为它会违反单一职责原则并导致 Constructor Over-Injection .

最好将细粒度的服务包装在更粗粒度的服务中。我称这些为 Aggregate Services或 抽象外墙 .虽然这些本身将具有依赖关系(例如您提到的服务端点)，但它们将是 实现细则 .从顶级消费者的角度来看，它们是不存在的。

这不仅很好地解决了构造函数中依赖过多的问题，还可以帮助您拥有 更好的隔离应用层之间。