我认为它们是正交的，可以一起使用。让我给你看一个我最近在工作中遇到的例子:

我们使用Java中的Spring框架进行DI。一个单例类(Parent)必须实例化另一个类(Child)的新对象，这些对象有复杂的协作者:

@Component
class Parent {
    // ...
    @Autowired
    Parent(Dep1 dep1, Dep2 dep2, ..., DepN depN) {
        this.dep1 = dep1;
        this.dep2 = dep2;
    }

    void method(int p) {
        Child c = new Child(dep1, dep2, ..., depN, p);
        // ...
    }
}

在这个例子中，Parent必须接收DepX实例，并将它们传递给Child构造函数。问题在于:

Parent对Child的了解比它应该了解的要多 母公司的合作者太多了 向Child添加依赖项需要更改Parent

这时我意识到工厂非常适合这里:

它隐藏了Child类的所有真实参数，就像Parent所看到的那样 它封装了创建子节点的知识，这些知识可以集中在DI配置中。

这是简化的Parent类和ChildFactory类:

@Component
class Parent {
    // ...
    @Autowired
    Parent(ChildFactory childFactory) {
        this.childFactory = childFactory;
    }

    void method(int p) {
        Child c = childFactory.newChild(p);
        // ...
    }
}

@Component
class ChildFactory {
    // ...
    @Autowired
    Parent(Dep1 dep1, Dep2 dep2, ..., DepN depN) {
        this.dep1 = dep1;
        this.dep2 = dep2;
        // ...
        this.depN = depN;
    }

    Child newChild(int p) {
        return new Child(dep1, dep2, ..., depN, p);
    }
}

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

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

但是…“不要白费力气”

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

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

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

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

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

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

理论

这里有两点需要考虑:

谁创建对象:

[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注入存储库并使用它来保存/查找正确的域类。

工厂设计模式

工厂设计模式的特点是

一个接口 实现类 一个工厂

当你这样问自己时，你可以观察到一些事情

工厂什么时候为实现类创建对象——运行时还是编译时? 如果您想在运行时切换实现，该怎么办?-不可能

这些是由依赖注入处理的。

依赖注入

您可以使用不同的方式注入依赖项。为了简单起见，让我们使用接口注入

在DI中，容器创建所需的实例，并将它们“注入”到对象中。

这样就消除了静态实例化。

例子:

public class MyClass{

  MyInterface find= null;

  //Constructor- During the object instantiation

  public MyClass(MyInterface myInterface ) {

       find = myInterface ;
  }

  public void myMethod(){

       find.doSomething();

  }
}

我相信DI是一种配置或即时化bean的方法。DI可以通过很多方式来实现，比如构造函数，setter-getter等等。

工厂模式只是实例化bean的另一种方式。此模式将主要用于必须使用工厂设计模式创建对象时，因为在使用此模式时，您不配置bean的属性，只实例化对象。

检查这个链接:依赖注入

我建议保持概念的简单明了。依赖注入更像是一种松散耦合软件组件的体系结构模式。工厂模式只是将创建其他类的对象的职责分离给另一个实体的一种方法。工厂模式可以被称为实现依赖注入的工具。依赖注入可以通过多种方式实现，比如使用构造函数进行依赖注入，使用映射xml文件等。