什么是IOC容器实际上在这里为我做什么？

Question

所以我完全重构了构造函数注入,现在我有一个类似于这个的bootstrapper类:

var container = new UnityContainer();
container.RegisterType<Type1, Impl1>();
container.RegisterType<Type2, Impl2>();
container.RegisterType<Type3, Impl3>();
container.RegisterType<Type4, Impl4>();

var type4Impl = container.Resolve((typeof)Type4) as Type4;
type4Impl.Run();

我盯着它看了一会儿才意识到Unity对我来说真的没什么特别的.离开ctor sigs,上面的内容可以写成:

Type1 type1Impl = Impl1();
Type2 type2Impl = Impl2();
Type3 type3Impl = Impl3(type1Impl, type2Impl);
Type4 type4Impl = Impl4(type1Impl, type3Impl);
type4Impl.Run();

构造函数注入重构很棒,真正打开了代码的可测试性.但是,我在这里怀疑Unity的用处.我意识到我可能以有限的方式使用框架(即不在任何地方注入容器,使用代码而不是XML进行配置,而不是利用生命周期管理选项),但是我没有看到它在这个示例中实际上是如何帮助的.我已经阅读了不止一条评论,他认为DI最好只用作模式,没有容器.这是一个很好的例子吗？这个解决方案提供了哪些其他好处,我错过了？

Answer 1

我发现当容器中有许多类型相互依赖时,DI容器会变得有价值.正是在这一点上,容器的自动连接能力闪耀.

如果您在获取对象时发现您指的是容器,那么您实际上是在遵循服务定位器模式.

Answer 2

请参阅我的帖子以获取对此问题的广泛答复。

这里的大多数其他答案都是正确的，并且说的几乎相同。我想补充一点，大多数 IoC 容器允许您将类型自动绑定到自身，或者按约定使用绑定。如果您设置 Unity 来执行此操作，那么您可以完全摆脱所有绑定代码。