IoC还有多远

Question

我想知道我应该在松散耦合应用程序方面采取IoC实施的程度.我在我的MVC控制器中使用构造函数注入但是想知道我是否也应该在控制器中解析所有其他依赖项而不是新建对象.例如,如果我要在控制器方法中创建一个新的User对象,我会使用吗？

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

我喜欢打破我对User的依赖的想法,但这样做太过分了,可能会让我的代码难以阅读？

Answer 1

这是一个非常好的问题,当你阅读和听到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.

级联依赖对象图:

在此示例中,对象上的新内容要么需要,要么创建一大堆其他依赖项.您很可能无法控制这些依赖关系是什么或做什么.

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