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

可能重复：
Arguments against Inversion of Control containers “IoC容器”中“容器”的用途是什么？

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

但是，IoC/DI本身没有带来什么目的，容器的目的是什么？由于涉及成本，所以能够分辨何时该成本合理化是很好的。

来源

2011-12-17 Arne Evertsson

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

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

您通常会从此类容器中获取所有分辨率。它有时也被称为内核。

来源

2011-12-17 17:46:24 ryber

容器是我描述的一个桶，其中接口的所有实现都处于活动状态，IOC在需要解析依赖关系时将其浸入桶中 – Burt 2011-12-17 18:26:42

何时可以更容易地解决您自己代码之外的依赖关系？你怎么知道你什么时候需要容器？ – 2011-12-17 18:35:23

我遵循“痛苦中的屁股”规则。一旦拥有一个容器，屁股上的疼痛就会少于没有一个。我添加一个。 – ryber 2011-12-17 23:21:23

我认为你需要保持术语清晰：

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

DI是依赖注入，这是一个代码单元没有新增其依赖性的想法，但从代码中获得它们来安装单元。再次wikipedia a has good article on DI。

将这两者结合意味着拥有一些集中化的东西，它负责将所有东西安置并解决依赖关系。无论什么centrized代码，这是IoC/DI容器。你可以自己写或使用现成的。

来源

2011-12-17 19:38:29

维基百科有关IoC的文章指出：“依赖注入是实现控制反转的主要方法”。看起来容器不在IoC的范围之内？ – 2011-12-19 22:46:51

依赖注入通过将依赖关系的连线移动到应用程序中的单个位置（启动路径也称为Composition Root），有助于使代码具有可维护性。这非常棒，因为Composition Root（就像您应用程序中的其他所有内容一样）承担一项责任。

当您的应用程序发展壮大时，您会发现这些类本身不会变得更复杂（当遵守SOLID原则时）。然而，组合根很快就会变得庞大而复杂，特别是在使用装饰器添加行为并按照惯例进行注册等操作时。

这是DI容器进场的地方。尽管SOLID原则可帮助您设计灵活且可维护的应用程序，但DI容器将帮助您保持Composition Root的可维护性。这是它唯一的目的。你用容器做的每一件事都可以在没有它的情况下完成，但是这往往会导致很多重复性和样板代码难以阅读和难以维护。

因此，DI容器的唯一目的就是让组合根可维护。

来源

2011-12-18 00:55:10 Steven

无论您保存在代码还是xml文件中，组合根目录是否会变得庞大而复杂？ – 2011-12-18 20:08:52

我尽可能避免使用XML配置，因为它很丑，并且没有编译时支持。良好的应用程序设计有助于简化组合根（CR）。例如，当围绕[命令模式]（http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91）和[查询模式]（http：// www .cuttingedge.it/blogs/steven/pivot/entry.php？id = 92），你会发现几乎所有东西都可以被容器自动注册。当您的CR变得复杂时，看看您的设计，开始使用DI容器或切换容器。 – Steven 2011-12-19 12:36:07

容器的责任是管理实例。

来源

2011-12-18 11:54:04

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

回答

相关问题