DI为您提供了一个组合根，这是连接对象图的一个集中位置。这往往使对象依赖关系非常显式，因为对象确切地要求它们所需要的东西，并且只有一个地方可以得到它。

组合根是一种清晰而直接的关注点分离。被注入的对象应该不依赖于DI机制，无论是第三方容器还是DIY DI。DI应该是不可见的。

工厂往往更加分散。不同的对象使用不同的工厂，工厂表示对象与其实际依赖关系之间的额外间接层。这个附加层将自己的依赖项添加到对象图中。工厂不是看不见的。工厂是一个中间商。

因此，更新工厂的问题更大:因为工厂是业务逻辑的依赖项，修改它们可能会产生连锁反应。组合根不是业务逻辑的依赖项，因此可以单独修改它。

GoF提到了更新抽象工厂的困难。他们的部分解释被引用在这里的回答中。将DI与工厂进行对比也与ServiceLocator是否是反模式这个问题有很多相似之处。

最终，选择哪个答案可能是固执己见的;但我认为这可以归结为一个工厂是一个中间人。问题在于，除了提供产品之外，这个中间商是否还能通过增加额外价值来发挥自己的作用。因为如果你能在没有中间商的情况下得到同样的产品，那为什么不把中间商去掉呢?

一个图表有助于说明其中的区别。

I believe, 3 important aspects govern objects and their usage: 1. Instantiation (of a class together with initialisation if any). 2. Injection (of the instance so created) where it's required. 3. Life cycle management (of the instance so created). Using Factory pattern, the first aspect (instantiation) is achieved but the remaining two is questionable. The class that uses other instances must hardcode the factories (instead of instances being created) which hinders loose coupling abilities. Moreover, life cycle management of instances becomes a challenge in a large application where a factory is used in multiple places (particularly, if the factory doesn't manage the life cycle of the instance it returns, it gets ugly). Using a DI (of IoC pattern) on the other hand, all the 3 are abstracted outside the code (to the DI container) and the managed bean needs nothing about this complexity. Loose Coupling, a very important architectural goal can be achieved quiet comfortably. Another important architectural goal, the separation of concerns can be achieved much better than factories.

尽管工厂可能适用于小型应用程序，但大型应用程序最好选择DI而不是工厂。

从表面上看，他们是一样的

简单来说，工厂模式，创建模式帮助我们创建一个对象——“定义一个创建对象的接口”。如果我们有一个键值类型的对象池(例如Dictionary)，将键传递给工厂(我指的是简单工厂模式)，您可以解析类型。完成工作! 另一方面，依赖注入框架(如结构图、Ninject、Unity等)似乎也在做同样的事情。

但是…“不要白费力气”

从架构的角度来看，这是一个绑定层，“不要白费力气”。

对于企业级应用程序，依赖注入的概念更像是一个定义依赖关系的体系结构层。为了进一步简化，您可以将其视为一个单独的类库项目，它进行依赖解析。主应用程序依赖于这个项目，其中依赖项解析器引用其他具体实现和依赖项解析。

除了来自Factory的“GetType/Create”之外，我们通常还需要更多的特性(使用XML定义依赖关系、模拟和单元测试等)。既然您引用了结构图，那么请查看结构图特性列表。这显然不仅仅是解决简单的对象映射。别白费力气了!

如果你只有一把锤子，那么所有东西看起来都像钉子

根据您的需求和您构建的应用程序类型，您需要做出选择。如果它只有很少的项目(可能是一个或两个..)并且涉及很少的依赖项，您可以选择一个更简单的方法。这就像使用ADO . net数据访问而不是使用实体框架进行简单的1或2个数据库调用，在这种情况下引入EF是多余的。

但是对于一个更大的项目，或者如果你的项目变得更大，我强烈建议有一个带有框架的DI层，并留出空间来改变你使用的DI框架(在主应用程序中使用Facade (Web应用程序，Web Api, Desktop..等)。

当我读到关于DI的文章时，我也有同样的问题。 最后，这就是我所理解的，但如果我错了，请纠正我。

“很久以前，有一些小国，它们有自己的管理机构，根据自己的成文规则进行控制和决策。后来形成了一个大政府，消除了所有这些小的管理机构，这些机构只有一套规则(宪法)，并通过法院执行。”

小王国的管理机构是“工厂”

大政府是“依赖注入器”。

这里的大多数答案都解释了两者的概念差异和实现细节。但是我无法解释在应用上的差异，IMO是最重要的，OP问的是什么。所以让我重新讨论这个话题……

曾经有人告诉我，你如何使用它才会有所不同!

完全正确。在90%的情况下，你可以使用Factory或DI来获取对象引用，通常你最终会使用后者。在另外10%的情况下，使用Factory是唯一正确的方法。这些情况包括通过运行时参数的变量获取对象。是这样的:

IWebClient client = factoryWithCache.GetWebClient(url: "stackoverflow.com",
        useCookies: false, connectionTimeout: 120);

在这种情况下，从DI获取客户端是不可能的(或者至少需要一些丑陋的解决方案)。因此，作为决策的一般规则:如果可以在没有任何运行时计算参数的情况下获得依赖项，则首选DI，否则使用Factory。

我相信DI是一种配置或即时化bean的方法。DI可以通过很多方式来实现，比如构造函数，setter-getter等等。

工厂模式只是实例化bean的另一种方式。此模式将主要用于必须使用工厂设计模式创建对象时，因为在使用此模式时，您不配置bean的属性，只实例化对象。

检查这个链接:依赖注入