注入框架是工厂模式的实现。

这完全取决于你的要求。如果您需要在应用程序中实现工厂模式，那么您的需求极有可能由众多注入框架实现中的一个来满足。

只有在任何第三方框架都不能满足您的需求时，您才应该推出自己的解决方案。编写的代码越多，需要维护的代码就越多。代码是一种负债而不是资产。

关于应该使用哪个实现的争论没有理解应用程序的体系结构需求那么重要。

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

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

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

注入框架是工厂模式的实现。

这完全取决于你的要求。如果您需要在应用程序中实现工厂模式，那么您的需求极有可能由众多注入框架实现中的一个来满足。

只有在任何第三方框架都不能满足您的需求时，您才应该推出自己的解决方案。编写的代码越多，需要维护的代码就越多。代码是一种负债而不是资产。

关于应该使用哪个实现的争论没有理解应用程序的体系结构需求那么重要。

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

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

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

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

当使用工厂时，您的代码实际上仍然负责创建对象。通过DI，你可以将职责外包给另一个类或框架，这与你的代码是分开的。

比诺，

我不认为你必须选择其中一个而不是另一个。

将依赖类或接口移动到类构造函数或setter的行为遵循DI模式。传递给构造函数或集合的对象可以用Factory实现。

什么时候使用?使用开发人员擅长的模式。他们觉得什么最舒服，什么最容易理解。