理论

这里有两点需要考虑:

谁创建对象:

[Factory]:你必须写如何创建对象。您有独立的Factory类，其中包含创建逻辑。 [依赖注入]:在实际情况下，这是由外部框架完成的(例如在Java中是spring/ejb/guice)。注入“神奇地”发生，无需显式地创建新对象。

它管理的对象类型:

[Factory]:通常负责有状态对象的创建 [依赖注入]:更可能创建无状态对象

关于如何在一个项目中同时使用工厂注入和依赖注入的实例

我们想要建造什么

用于创建包含多个名为orderline的条目的订单的应用程序模块。

体系结构

让我们假设我们想要创建以下分层架构:

域对象可以是存储在数据库中的对象。 存储库(DAO)帮助从数据库检索对象。 服务为其他模块提供API。允许对订单模块进行操作。

域层和工厂的使用

数据库中的实体是Order和OrderLine。Order可以有多个orderline。

现在是重要的设计部分。这个模块之外的模块是否应该自己创建和管理orderline ?不。只有当订单与之关联时，订单行才应该存在。最好能将内部实现隐藏到外部类。

但是如何在不了解OrderLines的情况下创建Order呢?

工厂

想要创建新订单的人使用了OrderFactory(它将隐藏关于我们如何创建订单的细节)。

这就是它在IDE中的样子。域包外部的类将使用OrderFactory而不是Order内部的构造函数。

依赖注入 依赖注入更常用于无状态层，如存储库和服务。

OrderRepository和OrderService由依赖注入框架管理。 存储库负责管理数据库上的CRUD操作。Service注入存储库并使用它来保存/查找正确的域类。

当您确切地知道此时需要什么类型的对象时，就可以使用依赖项注入。而在工厂模式的情况下，你只是把创建对象的过程委托给工厂，因为你不清楚你需要什么类型的对象。

从表面上看，他们是一样的

简单来说，工厂模式，创建模式帮助我们创建一个对象——“定义一个创建对象的接口”。如果我们有一个键值类型的对象池(例如Dictionary)，将键传递给工厂(我指的是简单工厂模式)，您可以解析类型。完成工作! 另一方面，依赖注入框架(如结构图、Ninject、Unity等)似乎也在做同样的事情。

但是…“不要白费力气”

从架构的角度来看，这是一个绑定层，“不要白费力气”。

对于企业级应用程序，依赖注入的概念更像是一个定义依赖关系的体系结构层。为了进一步简化，您可以将其视为一个单独的类库项目，它进行依赖解析。主应用程序依赖于这个项目，其中依赖项解析器引用其他具体实现和依赖项解析。

除了来自Factory的“GetType/Create”之外，我们通常还需要更多的特性(使用XML定义依赖关系、模拟和单元测试等)。既然您引用了结构图，那么请查看结构图特性列表。这显然不仅仅是解决简单的对象映射。别白费力气了!

如果你只有一把锤子，那么所有东西看起来都像钉子

根据您的需求和您构建的应用程序类型，您需要做出选择。如果它只有很少的项目(可能是一个或两个..)并且涉及很少的依赖项，您可以选择一个更简单的方法。这就像使用ADO . net数据访问而不是使用实体框架进行简单的1或2个数据库调用，在这种情况下引入EF是多余的。

但是对于一个更大的项目，或者如果你的项目变得更大，我强烈建议有一个带有框架的DI层，并留出空间来改变你使用的DI框架(在主应用程序中使用Facade (Web应用程序，Web Api, Desktop..等)。

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

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

这对于手动DI也是有效的(例如，当没有外部框架为你的对象提供依赖关系，但你在每个构造函数中传递它们时)。

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

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

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

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

我的想法:

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