您可以在这个链接中查看两种(和其他)方法在实际示例中的比较。

基本上，当需求发生变化时，如果您使用工厂而不是DI，您最终会修改更多的代码。

这对于手动DI也是有效的(例如，当没有外部框架为你的对象提供依赖关系，但你在每个构造函数中传递它们时)。

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

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

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

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

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

理论

这里有两点需要考虑:

谁创建对象:

[Factory]:你必须写如何创建对象。您有独立的Factory类，其中包含创建逻辑。 [依赖注入]:在实际情况下，这是由外部框架完成的(例如在Java中是spring/ejb/guice)。注入“神奇地”发生，无需显式地创建新对象。

它管理的对象类型:

[Factory]:通常负责有状态对象的创建 [依赖注入]:更可能创建无状态对象

关于如何在一个项目中同时使用工厂注入和依赖注入的实例

我们想要建造什么

用于创建包含多个名为orderline的条目的订单的应用程序模块。

体系结构

让我们假设我们想要创建以下分层架构:

域对象可以是存储在数据库中的对象。 存储库(DAO)帮助从数据库检索对象。 服务为其他模块提供API。允许对订单模块进行操作。

域层和工厂的使用

数据库中的实体是Order和OrderLine。Order可以有多个orderline。

现在是重要的设计部分。这个模块之外的模块是否应该自己创建和管理orderline ?不。只有当订单与之关联时，订单行才应该存在。最好能将内部实现隐藏到外部类。

但是如何在不了解OrderLines的情况下创建Order呢?

工厂

想要创建新订单的人使用了OrderFactory(它将隐藏关于我们如何创建订单的细节)。

这就是它在IDE中的样子。域包外部的类将使用OrderFactory而不是Order内部的构造函数。

依赖注入 依赖注入更常用于无状态层，如存储库和服务。

OrderRepository和OrderService由依赖注入框架管理。 存储库负责管理数据库上的CRUD操作。Service注入存储库并使用它来保存/查找正确的域类。

Life cycle management is one of the responsibilities dependency containers assume in addition to instantiation and injection. The fact that the container sometimes keep a reference to the components after instantiation is the reason it is called a "container", and not a factory. Dependency injection containers usually only keep a reference to objects it needs to manage life cycles for, or that are reused for future injections, like singletons or flyweights. When configured to create new instances of some components for each call to the container, the container usually just forgets about the created object.

来自:http://tutorials.jenkov.com/dependency-injection/dependency-injection-containers.html

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而不是工厂。

IOC is a concept which is implemented by two ways. Dependency creation and dependency injection, Factory/Abstract factory are the example of dependency creation. Dependency injection is constructor, setter and interface. The core of IOC is to not depend upon the concrete classes, but define the abstract of methods(say an Interface/abstract class) and use that abstract to call method of concrete class. Like Factory pattern return the base class or interface. Similariliy dependency injection use base class/interface to set value for objects.