引用的大多数使用依赖注入的例子，我们也可以使用工厂模式来解决。看起来当涉及到使用/设计时，依赖注入和工厂之间的区别是模糊或稀薄的。
曾经有人告诉我，你如何使用它才会有所不同!
我曾经使用StructureMap一个DI容器来解决一个问题，后来我重新设计了它来使用一个简单的工厂，并删除了对StructureMap的引用。
谁能告诉我它们之间的区别在哪里使用什么，这里的最佳实践是什么?
当前回答
如果传递的参数可以在工厂中分组，那么它也是构造函数过度注入的一个很好的解决方案，看看下面的代码*):
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。
其他回答
当您确切地知道此时需要什么类型的对象时，就可以使用依赖项注入。而在工厂模式的情况下，你只是把创建对象的过程委托给工厂，因为你不清楚你需要什么类型的对象。
如果传递的参数可以在工厂中分组，那么它也是构造函数过度注入的一个很好的解决方案，看看下面的代码*):
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。
当我读到关于DI的文章时，我也有同样的问题。 最后，这就是我所理解的，但如果我错了，请纠正我。
“很久以前，有一些小国，它们有自己的管理机构，根据自己的成文规则进行控制和决策。后来形成了一个大政府，消除了所有这些小的管理机构，这些机构只有一套规则(宪法)，并通过法院执行。”
小王国的管理机构是“工厂”
大政府是“依赖注入器”。
使用依赖注入框架，开发人员不需要手动准备和设置类实例的依赖项，这一切都是事先准备好的。
对于工厂，开发人员必须手工完成，并使用这些依赖对象创建类实例。
区别主要在于这一行中调用工厂并获取构造的对象，以及编写工厂方法来创建和设置所有内容(尽管可以认为，在依赖注入框架中，通过连接和配置对象关系，这也必须在一定程度上完成)。
如果是工厂，你就得打电话给任何需要这种东西的工厂。 使用依赖注入框架，你可以在类实例创建时依赖对象的存在。
我的观点是，工厂方法更静态，因为它的实现相当固定，而依赖注入框架更动态，因为类实例的实际组合更容易改变(例如。为了测试目的)在运行时。
从表面上看，他们是一样的
简单来说，工厂模式，创建模式帮助我们创建一个对象——“定义一个创建对象的接口”。如果我们有一个键值类型的对象池(例如Dictionary)，将键传递给工厂(我指的是简单工厂模式)，您可以解析类型。完成工作! 另一方面，依赖注入框架(如结构图、Ninject、Unity等)似乎也在做同样的事情。
但是…“不要白费力气”
从架构的角度来看，这是一个绑定层，“不要白费力气”。
对于企业级应用程序，依赖注入的概念更像是一个定义依赖关系的体系结构层。为了进一步简化，您可以将其视为一个单独的类库项目，它进行依赖解析。主应用程序依赖于这个项目，其中依赖项解析器引用其他具体实现和依赖项解析。
除了来自Factory的“GetType/Create”之外，我们通常还需要更多的特性(使用XML定义依赖关系、模拟和单元测试等)。既然您引用了结构图，那么请查看结构图特性列表。这显然不仅仅是解决简单的对象映射。别白费力气了!
如果你只有一把锤子，那么所有东西看起来都像钉子
根据您的需求和您构建的应用程序类型，您需要做出选择。如果它只有很少的项目(可能是一个或两个..)并且涉及很少的依赖项，您可以选择一个更简单的方法。这就像使用ADO . net数据访问而不是使用实体框架进行简单的1或2个数据库调用，在这种情况下引入EF是多余的。
但是对于一个更大的项目，或者如果你的项目变得更大，我强烈建议有一个带有框架的DI层，并留出空间来改变你使用的DI框架(在主应用程序中使用Facade (Web应用程序，Web Api, Desktop..等)。
