3

I was wondering how far I should take my IoC implementation in terms of loosely coupling my application. I am using constructor injection in my MVC controller but wondered if I should also be resolving all my other dependencies in the controller instead of newing up objects. For example if I was to create a new User object within a controller method would I use?

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

I like the idea of breaking my dependency on User but is that going too far and could possible make my code harder to read?

4

1 回答 1

5

这是一个非常好的问题，当您阅读和听说 DI 时，这是有道理的，这是下一个自然结论。

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

塞巴斯蒂安还发布了一个很好的链接。

实际上，我在此处发布的答案中对此进行了描述。

帖子底部：

并非每个对象和依赖项都需要或应该被依赖注入，首先考虑您正在使用的内容是否实际上被视为依赖项：

什么是依赖项？

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

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

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

List
MemoryStream
Strings/Primitives
Leaf Objects/Dto's

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

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

级联依赖对象图：

依赖图

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

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

于 2012-05-30T19:07:21.093 回答