依赖注入与工厂模式的区别

IOC是由两种方式实现的概念。依赖创建和依赖注入，工厂/抽象工厂是依赖创建的例子。依赖注入是构造函数、setter和接口。IOC的核心是不依赖于具体的类，而是定义方法的抽象（比如一个接口/抽象类），并使用该抽象调用具体类的方法。就像工厂模式返回基类或接口一样。同样，依赖注入使用基类/接口为对象设置值。

使用依赖注入框架，开发者无需手动准备和设置类实例的依赖项，所有的都已预先准备好了。
使用工厂时，开发者需要手动完成这些工作，并使用这些依赖对象创建类实例。
区别主要在于调用工厂并获取构造对象的那一行代码，以及编写创建和设置所有内容的工厂方法（尽管可以认为使用依赖注入框架也必须在一定程度上完成这一点，通过连接和配置对象关系）。
然后，使用工厂需要在需要此类对象的任何位置调用工厂。使用 DI 框架，您通常可以在类实例创建时依赖于对象的存在。
我的看法是，工厂方法更加静态，因为其实现相当固定，而依赖注入框架更加动态，因为类实例的实际组成可以更轻松地在运行时进行更改（例如，用于测试目的）。

我的想法：

依赖注入：将协作者作为参数传递给构造函数。 依赖注入框架：一个通用且可配置的工厂，用于创建作为参数传递给构造函数的对象。

通过使用工厂，您可以将相关接口分组。因此，如果传递的参数可以在工厂中进行分组，那么它也是解决构造函数过度注入的好方法，请参考以下代码*）：

public AddressModelFactory(IAddressAttributeService addressAttributeService,
        IAddressAttributeParser addressAttributeParser,
        ILocalizationService localizationService,
        IStateProvinceService stateProvinceService,
        IAddressAttributeFormatter addressAttributeFormatter)
    {
        this._addressAttributeService = addressAttributeService;
        this._addressAttributeParser = addressAttributeParser;
        this._localizationService = localizationService;
        this._stateProvinceService = stateProvinceService;
        this._addressAttributeFormatter = addressAttributeFormatter;
    }

看一下构造函数，你只需要传递IAddressModelFactory，因此参数更少 *）：

 public CustomerController(IAddressModelFactory addressModelFactory,
        ICustomerModelFactory customerModelFactory,
        IAuthenticationService authenticationService,
        DateTimeSettings dateTimeSettings,
        TaxSettings taxSettings,
        ILocalizationService localizationService,
        IWorkContext workContext,
        IStoreContext storeContext,
        ICustomerService customerService,
        ICustomerAttributeParser customerAttributeParser,
        ICustomerAttributeService customerAttributeService,
        IGenericAttributeService genericAttributeService,
        ICustomerRegistrationService customerRegistrationService,
        ITaxService taxService,
        CustomerSettings customerSettings,
        AddressSettings addressSettings,...

您在 CustomerController 中看到了许多传递的参数，是的，您可以将其视为 构造函数过度注入 但这就是 DI 的工作原理。并且 CustomerController 没有任何问题。

*) 代码来自 nopCommerce。

大多数答案都解释了两者的概念差异和实现细节。然而，我无法找到关于应用程序差异的解释，这是我认为最重要的，并且OP也在询问。因此，让我们重新开启这个话题...

有人曾告诉我，使用方式才是真正的区别所在！

没错。在90%的情况下，您可以使用工厂或DI来获取对象引用，通常您最终会选择后者。在另外10%的情况下，使用工厂是唯一正确的方法。这些情况包括通过变量在运行时参数中获取对象。像这样：

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

在这种情况下，从 DI 中获取 client 不可能（或至少需要一些丑陋的解决方法）。因此，作为一个通用规则来做决策：如果可以在没有任何运行时计算参数的情况下获取依赖项，则优先使用 DI，否则使用工厂。

当我读到DI时，我也有同样的问题，并最终看到了这篇文章。所以，这是我理解的内容，请纠正我如果我理解错了。
“很久以前，有许多小王国，它们有自己的管理机构，根据自己制定的规则做出决策。后来形成了一个大政府，消除了所有这些小管理机构，只有一套规则（宪法），并通过法院实施。”
小王国的管理机构就是“工厂”。
大政府就是“依赖注入器”。

您可以查看此链接，以了解在实际示例中两种（和其他）方法的比较。
基本上，如果使用工厂而不是 DI，则在需求变更时需要修改更多的代码。
这也适用于手动 DI（即当没有外部框架为您的对象提供依赖项时，但您会在每个构造函数中传递它们）。

简单来说，依赖注入和工厂方法意味着推送和拉取机制。拉取机制：类间接地依赖于工厂方法，后者又依赖于具体类。推送机制：根组件可以在一个位置配置所有依赖组件，从而促进高维护性和松散耦合。使用工厂方法时，责任仍然在类上（虽然是间接的）创建新对象，而使用依赖注入，则将该责任外包（代价是泄漏抽象）。

当您确切知道需要哪些对象时，可以使用依赖注入。而在工厂模式中，由于您不确定需要哪种类型的对象，因此只需将对象创建过程委托给工厂即可。

我认为，有三个重要方面影响对象及其使用：
1. 实例化（类的实例化以及初始化）。
2. 注入（所创建的实例在需要时进行注入）。
3. 生命周期管理（所创建的实例的生命周期管理）。

使用工厂模式可以实现第一个方面（实例化），但是剩下的两个方面存在问题。使用其他实例的类必须硬编码工厂（而不是创建实例），这会阻碍松耦合的能力。此外，在大型应用程序中使用工厂在多个地方使用时，实例的生命周期管理将成为一项挑战（特别是如果工厂不管理它返回的实例的生命周期，情况将变得很糟糕）。

另一方面，使用DI（IoC模式）将所有三个方面抽象到代码之外（到DI容器），托管的bean与此复杂性无关。可以轻松实现非常重要的架构目标松散耦合。比工厂更好地实现了另一个重要的架构目标关注点分离。

虽然工厂可能适用于小型应用程序，但大型应用程序最好选择DI而不是工厂。