“IoC容器”中“容器”的用途是什么？

Question

  

可能重复：
  Arguments against Inversion of Control containers

使用IoC（或依赖注入，DI）确实有助于创建可重用的组件。据称DI也有用于测试课程的好处。

但是，单独使用IoC / DI的容器的目的是什么呢？由于涉及成本，因此能够判断该成本何时合理是很好的。

Answer 1

IOC系统中的“容器”是包含如何解决依赖关系的映射的组件。例如，它会知道当询问IFoo接口的依赖关系时，它会解析为FooImpl。

您通常必须在某处执行这些映射。通过配置文件，注释或其他运行时组件。

您通常会从这样的容器中获得所有分辨率。它有时也被称为内核。

Answer 2

通过移动依赖关系连接到应用程序中的单个位置（启动路径a.k.a. Composition Root）的连接，依赖注入有助于使代码可维护。这很好，因为组合根（就像你应用程序中的其他所有东西一样）只有一个责任。

当你的应用程序不断发展和成长时，你会发现类本身自身并没有那么复杂（当遵守SOLID原则时）。然而，组合根将非常快速地变得庞大而复杂，特别是在使用装饰器添加行为和按照惯例执行注册时。

这是DI容器的用武之地。虽然SOLID原则可帮助您设计灵活且可维护的应用程序，但DI容器将帮助您保持组合根的可维护性。这是它的唯一目的。使用容器完成的所有操作都可以在没有它的情况下完成，但这通常会导致很多重复和样板代码难以阅读且难以维护。

同样，DI容器的唯一目的是使组合物可维持。

Answer 3

我认为您需要明确术语：

IoC 是控制反转，这是系统主流由应用核心之外的东西处理的原则。也就是说，有一个容器可以协调执行，并且有应用程序代码封装了业务逻辑。 wikipedia article on IoC提供了很好的解释。

DI 是依赖注入，这意味着代码单元不会新增其依赖关系，而是从实现单元的代码中获取它们。再次wikipedia a has good article on DI。

将这两者结合起来意味着集中进行反转，这需要负责实现一切并解决依赖关系。无论中心化代码是什么，这都是IoC / DI容器。您可以自己编写或使用现成的。

Answer 4

容器的责任是管理实例。