dependency-injection - IoC还有多远

Question

我想知道在应用程序松散耦合方面，我的 IoC 实现应该走多远。我在我的 MVC Controller 中使用构造函数注入(inject)，但想知道我是否还应该解决 Controller 中的所有其他依赖项而不是更新对象。例如，如果我要在 Controller 方法中创建一个新的用户对象，我会使用吗？

var user = new User();
var user = myContainer.Resolve<IUser>();

我喜欢打破对 User 的依赖的想法，但这样做是否太过分了，可能会使我的代码更难阅读？

Answer 1

这是一个很好的问题，当您阅读和听到有关 DI 的内容时，这是有道理的，这是下一个自然的结论。

首先史蒂文的观点是正确的，你不应该传递容器。如果您需要动态构建 IUser 并且它需要抽象，您应该注入(inject)一个抽象工厂。

Sebastian 也发布了一个很好的链接。

我实际上在我发布的一个答案中写了这个 here .

帖子的底部:

不是每个对象和依赖项都需要或应该被依赖注入(inject)，首先要考虑你使用的是否真的被认为是一个依赖项:

什么是依赖关系？

Application Configuration
System Resources (Clock)
Third Party Libraries
Database
WCF/Network Services
External Systems (File/Email)

上述任何对象或合作者都可能不受您的控制，并导致副作用和行为差异，并使其难以测试。现在是考虑抽象(类/接口(interface))和使用 DI 的时候了。

什么不是依赖，真的不需要 DI？

List
MemoryStream
Strings/Primitives
Leaf Objects/Dto's

因此，在您的特定情况下，它实际上取决于构造 IUser 时发生的情况，以及您是否真的需要用不同的实现来替换它。如果不是这种情况，并且 User 只有简单的类型，没有外部依赖或副作用，那就新建它。

考虑调用 new User() 时会发生什么，看看下图，如果它导致创建其他对象并且看起来像下图中的东西，请考虑 IoC。

级联依赖对象图:

在此示例中，对象上的 new 需要或创建一大堆其他依赖项。您很可能无法控制这些依赖项是什么或做什么。

当你的对象是一个简单的 dto 时，它不会遇到这个问题，并且 IoC 可能不是那么需要。