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

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

这对于手动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。

这里的大多数答案都解释了两者的概念差异和实现细节。但是我无法解释在应用上的差异，IMO是最重要的，OP问的是什么。所以让我重新讨论这个话题……

曾经有人告诉我，你如何使用它才会有所不同!

完全正确。在90%的情况下，你可以使用Factory或DI来获取对象引用，通常你最终会使用后者。在另外10%的情况下，使用Factory是唯一正确的方法。这些情况包括通过运行时参数的变量获取对象。是这样的:

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

在这种情况下，从DI获取客户端是不可能的(或者至少需要一些丑陋的解决方案)。因此，作为决策的一般规则:如果可以在没有任何运行时计算参数的情况下获得依赖项，则首选DI，否则使用Factory。

[Factory] ->有一个基于请求参数创建类的类。毕竟，“工厂”在现实世界中也为你制造“物品”。你可以让你的汽车供应商工厂生产(免费:)特斯拉。1给你。

[DI] ->一个(服务)容器，用于存储接口(压缩类)。你不关心创建对象。你只需要让某个人/某个地方实现它，细节和其他东西对你、调用者或消费者都不重要。

DI是SOLID原则中“D”的基础。

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

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

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

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

比诺，

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

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

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