di容器vs.工厂

本文关键字：工厂 vs 容器 di | 更新日期: 2023-09-27 18:01:47

我知道有很多关于依赖注入的文章和话题，但关于依赖注入容器的文章和话题并不多。我发现这个由Fabien Potencier编写的非常有用，尽管它针对PHP。然而，我读了更多关于这些容器我得出的结论，这是一个简单的工厂方法的集合，这是真的吗?

更深入、更具体的观点:当向对象注入依赖项时

foo.Bar = new Dependency();

我也可以写

foo.Bar = new myFactory.CreateDependency();

或与容器

连用
foo.Bar = myContainer.CreateDependency();

最后一种方法中的容器不仅有一个，而且还有许多其他方法来创建其他类型，所以它只是工厂方法的容器，对吗?

di容器vs.工厂

使用DI容器的关键在于您永远不需要/不应该编写像

这样的代码
foo.Bar = myContainer.CreateDependency();

被认为是一个反模式。DI容器应该只在Composition根目录下使用一次(这是一个主要的DI容器使用模式)。

DI容器根据配置自动构造对象并通过构造函数或属性注入依赖项。在工厂的情况下，你必须自己做一切。除了创建之外，DI容器还提供:

生命周期管理。因此，每次需要依赖时，容器可能会注入相同的对象(单例生命周期)，或者每次都返回new。

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

你可以看看。net中的依赖注入这本书。它帮助我理解了DI容器、使用模式和依赖注入。

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

另一方面，你自己的工厂是定制的，通常包含具体实现列表和大开关箱，或映射或类似的东西。它们工作得更快，但是你必须自己编写所有的对象构造逻辑。

你不必在这两个选项中选择一个，你可以把它们组合起来。例如，您可以通过DI

构造复杂的工厂。

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

理想情况下，代码应该不知道它正在使用DI运行。它只是外部化了它的依赖项，并假设它们已经提供了。

相关文章：