引用的大多数使用依赖注入的例子，我们也可以使用工厂模式来解决。看起来当涉及到使用/设计时，依赖注入和工厂之间的区别是模糊或稀薄的。
曾经有人告诉我，你如何使用它才会有所不同!
我曾经使用StructureMap一个DI容器来解决一个问题，后来我重新设计了它来使用一个简单的工厂，并删除了对StructureMap的引用。
谁能告诉我它们之间的区别在哪里使用什么，这里的最佳实践是什么?
当前回答
简单来说，依赖注入和工厂方法分别意味着推和拉机制。
拉机制:类间接依赖于工厂方法，工厂方法又依赖于具体类。
推送机制:根组件可以在一个位置配置所有依赖组件，从而促进高维护和松耦合。
使用Factory方法时，创建新对象的责任仍然由类承担(尽管是间接的)，而使用依赖注入时，责任是外包的(尽管是以泄露抽象为代价)。
其他回答
我相信DI是一种配置或即时化bean的方法。DI可以通过很多方式来实现，比如构造函数，setter-getter等等。
工厂模式只是实例化bean的另一种方式。此模式将主要用于必须使用工厂设计模式创建对象时，因为在使用此模式时，您不配置bean的属性，只实例化对象。
检查这个链接:依赖注入
当我读到关于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).
工厂抽象了域对象和服务的一些构造。但是领域对象和服务仍然负责弄清楚如何构造自己，以及如何获得它们所依赖的所有东西。所有这些“活动的”依赖项都会在应用程序的所有层中进行筛选。没有一个地方可以配置所有的东西。
当使用工厂时，您的代码实际上仍然负责创建对象。通过DI，你可以将职责外包给另一个类或框架，这与你的代码是分开的。
在我看来，使用依赖注入更好，如果你是: 1. 将代码部署在小分区中，因为它可以很好地解耦一个大代码。 2. 可测试性是DI可以使用的情况之一，因为你可以很容易地模拟非去耦的对象。通过使用接口，您可以轻松地模拟和测试每个对象。 3.你可以同时修改程序的每一部分，而不需要编码它的另一部分，因为它是松散解耦的。
