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.

我相信DI是工厂的一种抽象层，但是它们还提供了抽象之外的好处。真正的工厂知道如何实例化单一类型并配置它。好的DI层通过配置提供实例化和配置多种类型的能力。

显然，对于具有一些简单类型的项目(在其构造中需要相对稳定的业务逻辑)，工厂模式易于理解、实现并且工作良好。

OTOH，如果您有一个包含许多类型的项目，您希望经常更改这些类型的实现，DI通过其配置为您提供了在运行时执行此操作的灵活性，而无需重新编译工厂。

有些问题用依赖注入很容易解决，而用一套工厂就不那么容易解决了。

一方面，控制反转和依赖注入(IOC/DI)与另一方面，服务定位器或工厂套件(factory)之间的一些区别是:

IOC/DI is a complete ecosystem of domain objects and services in and of itself. It sets everything up for you in the way you specify. Your domain objects and services are constructed by the container, and do not construct themselves: they therefore do not have any dependencies on the container or on any factories. IOC/DI permits an extremely high degree of configurability, with all the configuration in a single place (construction of the container) at the topmost layer of your application (the GUI, the Web front-end).

工厂抽象了域对象和服务的一些构造。但是领域对象和服务仍然负责弄清楚如何构造自己，以及如何获得它们所依赖的所有东西。所有这些“活动的”依赖项都会在应用程序的所有层中进行筛选。没有一个地方可以配置所有的东西。

简单来说，依赖注入和工厂方法分别意味着推和拉机制。

拉机制:类间接依赖于工厂方法，工厂方法又依赖于具体类。

推送机制:根组件可以在一个位置配置所有依赖组件，从而促进高维护和松耦合。

使用Factory方法时，创建新对象的责任仍然由类承担(尽管是间接的)，而使用依赖注入时，责任是外包的(尽管是以泄露抽象为代价)。

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

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

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

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