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

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

检查这个链接:依赖注入

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通过其配置为您提供了在运行时执行此操作的灵活性，而无需重新编译工厂。

我建议保持概念的简单明了。依赖注入更像是一种松散耦合软件组件的体系结构模式。工厂模式只是将创建其他类的对象的职责分离给另一个实体的一种方法。工厂模式可以被称为实现依赖注入的工具。依赖注入可以通过多种方式实现，比如使用构造函数进行依赖注入，使用映射xml文件等。

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

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

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

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

使用依赖注入框架，开发人员不需要手动准备和设置类实例的依赖项，这一切都是事先准备好的。

对于工厂，开发人员必须手工完成，并使用这些依赖对象创建类实例。

区别主要在于这一行中调用工厂并获取构造的对象，以及编写工厂方法来创建和设置所有内容(尽管可以认为，在依赖注入框架中，通过连接和配置对象关系，这也必须在一定程度上完成)。

如果是工厂，你就得打电话给任何需要这种东西的工厂。 使用依赖注入框架，你可以在类实例创建时依赖对象的存在。

我的观点是，工厂方法更静态，因为它的实现相当固定，而依赖注入框架更动态，因为类实例的实际组合更容易改变(例如。为了测试目的)在运行时。