我使用这两种方法来创建反转控制策略，为在我之后需要维护它的开发人员提供了更强的可读性。

我使用工厂来创建不同的层对象(业务，数据访问)。

ICarBusiness carBusiness = BusinessFactory.CreateCarBusiness();

另一个开发人员会看到这一点，当创建业务层对象时，他会在BusinessFactory中查看，智能感知会为开发人员提供所有可能创建的业务层。不需要玩游戏，找到我想要创建的界面。

这个结构已经是控制反转了。我不再负责创建特定的对象。但是您仍然需要确保依赖注入能够轻松地更改内容。 创建自己的自定义依赖注入是荒谬的，所以我使用Unity。在CreateCarBusiness()中，我要求Unity解决哪个类属于这个和它的生命周期。

所以我的代码工厂依赖注入结构是:

public static class BusinessFactory
{
    public static ICarBusiness CreateCarBusiness()
    {
       return Container.Resolve<ICarBusiness>();
    }
}

现在我两者兼得。我的代码对于其他开发人员来说也更易于阅读，因为我使用的对象的范围，而不是构造函数依赖注入，它只是说在创建类时每个对象都是可用的。

当我创建单元测试时，我使用它将我的数据库数据访问更改为自定义编码的数据访问层。我不希望我的单元测试与数据库、网络服务器、电子邮件服务器等通信。他们需要测试我的业务层，因为这是智能所在。

DI为您提供了一个组合根，这是连接对象图的一个集中位置。这往往使对象依赖关系非常显式，因为对象确切地要求它们所需要的东西，并且只有一个地方可以得到它。

组合根是一种清晰而直接的关注点分离。被注入的对象应该不依赖于DI机制，无论是第三方容器还是DIY DI。DI应该是不可见的。

工厂往往更加分散。不同的对象使用不同的工厂，工厂表示对象与其实际依赖关系之间的额外间接层。这个附加层将自己的依赖项添加到对象图中。工厂不是看不见的。工厂是一个中间商。

因此，更新工厂的问题更大:因为工厂是业务逻辑的依赖项，修改它们可能会产生连锁反应。组合根不是业务逻辑的依赖项，因此可以单独修改它。

GoF提到了更新抽象工厂的困难。他们的部分解释被引用在这里的回答中。将DI与工厂进行对比也与ServiceLocator是否是反模式这个问题有很多相似之处。

最终，选择哪个答案可能是固执己见的;但我认为这可以归结为一个工厂是一个中间人。问题在于，除了提供产品之外，这个中间商是否还能通过增加额外价值来发挥自己的作用。因为如果你能在没有中间商的情况下得到同样的产品，那为什么不把中间商去掉呢?

一个图表有助于说明其中的区别。

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

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

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

我的想法:

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

在我看来，使用依赖注入更好，如果你是: 1. 将代码部署在小分区中，因为它可以很好地解耦一个大代码。 2. 可测试性是DI可以使用的情况之一，因为你可以很容易地模拟非去耦的对象。通过使用接口，您可以轻松地模拟和测试每个对象。 3.你可以同时修改程序的每一部分，而不需要编码它的另一部分，因为它是松散解耦的。

如果传递的参数可以在工厂中分组，那么它也是构造函数过度注入的一个很好的解决方案，看看下面的代码*):

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。