“容器”的用途是什么？在“IoC 容器”中？
可能的重复：
反对控制反转容器的争论
确实使用 IoC（或依赖注入，DI）有助于创建可重用的组件。据称，DI 对于测试类也有好处。
但是，仅 IoC/DI 尚未带来的容器的用途是什么？由于涉及成本，因此最好能够知道该成本何时变得合理。
Possible Duplicate:
Arguments against Inversion of Control containers
Using IoC (or Dependency Injection, DI) really helps in the creation of reusable components. DI also has benefits, it has been claimed, for testing your classes.
But, what is the purpose of the container that IoC/DI alone doesn't already bring to the table? Since there is a cost involved it would be nice to be able to tell when that cost becomes justified.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
IOC 系统中的“容器”是包含如何解决依赖关系的映射的组件。例如，它知道当请求 IFoo 接口的依赖项时，它将解析为 FooImpl。
您通常必须在某处执行这些映射。通过配置文件、注释或其他运行时组件。
您通常可以从这样的容器中获得所有解析。有时也称为内核。
The "container" in IOC systems is the component that contains the mappings for how to resolve dependencies. For example it would know that when a dependency of a interface of IFoo was asked for it would resolve to FooImpl.
You typically have to perform these mappings somewhere. Either through a config file, annotations or other runtime components.
You typically get all resolution from such a container. It is also sometimes called a kernel.
依赖注入通过将依赖项连接到应用程序中的单个位置（启动路径又名 组合根）。这很棒，因为组合根（就像应用程序中的其他所有内容一样）具有单一职责。
当您的应用程序不断发展和增长时，您会发现类本身并没有变得更加复杂（当遵守 SOLID 原则）。然而，组合根很快就会变得庞大且复杂，尤其是在使用装饰器添加行为以及按照惯例进行注册等操作时。
这就是 DI 容器发挥作用的地方。虽然 SOLID 原则可以帮助您设计灵活且可维护的应用程序，但 DI 容器将帮助您保持组合根的可维护性。这是它的唯一目的。使用容器做的所有事情都可以在没有容器的情况下完成，但这通常会导致大量重复的样板代码，这些代码难以阅读和维护。
同样，DI 容器的唯一目的是使组合根可维护。
Dependency injection helps making your code maintainable, by moving the wiring of the way dependencies are wired to a single place in the application (the start-up path a.k.a. Composition Root). This is great, since that Composition Root has (just as everything else in your application) a single responsibility.
When your application will evolve and grow, you will see that classes themselves don't get much more complex by themselves (when adhering to the SOLID principles). The Composition Root however, will get big and complex very quickly, especially when using decorators to add behavior and doing things like registration by convention.
This is where a DI container comes in play. While the SOLID principles help you in designing an application that is flexible and maintainable, a DI container will help you keep the Composition Root maintainable. That's its sole purpose. Everything you do with a container can be done without it, but this will often result in a lot of repetitive and boilerplate code that is hard to read and hard to maintain.
So again, the sole purpose of a DI container is to make the composition root maintainable.
我认为你需要保持术语清晰：
IoC是控制反转，这是系统的主要流程由应用程序核心之外的东西处理的原则。也就是说，有一个编排执行的容器，并且有封装业务逻辑的应用程序代码。 关于 IoC 的维基百科文章给出了很好的解释。
DI 是依赖注入，即代码单元不会更新其依赖项，而是从实例化该单元的代码中获取它们。再次wikipedia 有关于 DI 的好文章。
将这两者结合起来意味着拥有一个中心化的东西，它负责初始化一切并解决依赖关系。无论集中式代码做什么，这都是 IoC/DI 容器。您可以自己编写或使用现成的。
I think you need to keep the terminology clear:
IoC is Inversion of Control, which is the principle that the main flow of the system is handled by something outside the application core. That is there is a container of sorts that orchestrates the execution and there is the application code that encapsulates the business logic. The wikipedia article on IoC gives a pretty good explaination.
DI is dependency injection which is the idea that a unit of code does not new up its dependencies, but gets them from the code that instatiates the unit. Again wikipedia a has good article on DI.
Combining those two means having something centralized that inverts that takes the responsibility of instatiating everything and resolving dependencies. Whatever centrlized code does this is the IoC/DI container. You can write it yourself or use a off-the-shelf one.
容器的职责是管理实例。
Containers responsibility is to manage instances.