DI容器与工厂

Question

我知道Dependency Injection上有很多aricle和线程，但Depenedency-Injection-Containers没有那么多。 我发现Fabien Potencier的这个很有帮助，虽然它针对的是PHP。 然而，我越了解这些容器，我得出的结论是，这不仅仅是一个简单的工厂方法集合，这是真的吗？

更深入，更具体的视图：向对象注入依赖项时

foo.Bar = new Dependency();

我也可以写

foo.Bar = new myFactory.CreateDependency();

或用容器

foo.Bar = myContainer.CreateDependency();

这里最后一种方法中的容器也没有一个但很多其他方法来创建其他类型，所以它只是工厂方法的容器，对吧？

Answer 1

DI容器的重点是你永远不需要/应该写代码

foo.Bar = myContainer.CreateDependency();

它被认为是反模式。 DI容器只能在Composition Root中使用一次（它是主要的DI容器使用模式）。

DI容器根据配置自动构造对象并通过构造函数或属性注入依赖项。 如果是工厂，你必须自己做所有事情。 除了创造DI容器为您提供：

LifeTime管理。 因此，每次需要依赖项时，容器可能会注入相同的对象（单例生存期），或者每次都返回new。

有限的AOP功能，例如方法调用拦截和在方法之前和之后执行自定义逻辑。

您可以在.NET中查看本书的依赖注入 。 一般来说，理解DI容器，使用模式和依赖注入对我有很大的帮助。

Answer 2

您可以将DI-container / library视为具有大量高级对象构造方法（通过反射）的工厂框架。 它很有用，因为通常您不必编写任何高级方法，例如，用于加载插件程序集和获取插件数据类型。 但缺点是反射很慢，在应用程序初始化阶段使用它是合理的。 但是，如果你想在运行时用它创建很多小对象，它会减慢你的速度。

另一方面，您自己的工厂是定制的，通常包含具体实现和大型开关案例列表，或地图或类似的东西。 它们的工作速度更快，但您必须自己编写所有对象构造逻辑。

您无需在这两个选项之间进行选择即可将它们组合在一起。 例如，您可以通过DI构建复杂的工厂

Answer 3

DI-Container可被视为一组大型智能工厂方法，使用多种方式（代码，xml，自动映射）进行配置。 我称这些工厂方法是智能的，因为容器跟踪其注册类型并使用它们来创建更复杂的对象。 使用工厂时，您需要自己设置这些依赖项，否则您已经在使用依赖项容器。

Answer 4

理想情况下，代码应该不知道它与DI一起运行。 它只是将其依赖项外部化并假设它们已被提供。