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

我们使用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);
    }
}

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

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

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

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

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

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

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

当使用工厂时，您的代码实际上仍然负责创建对象。通过DI，你可以将职责外包给另一个类或框架，这与你的代码是分开的。

我的想法:

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

注入框架是工厂模式的实现。

这完全取决于你的要求。如果您需要在应用程序中实现工厂模式，那么您的需求极有可能由众多注入框架实现中的一个来满足。

只有在任何第三方框架都不能满足您的需求时，您才应该推出自己的解决方案。编写的代码越多，需要维护的代码就越多。代码是一种负债而不是资产。

关于应该使用哪个实现的争论没有理解应用程序的体系结构需求那么重要。

依赖注入

而不是实例化部件本身，汽车要求它的功能所需的部件。

class Car
{
    private Engine engine;
    private SteeringWheel wheel;
    private Tires tires;

    public Car(Engine engine, SteeringWheel wheel, Tires tires)
    {
        this.engine = engine;
        this.wheel = wheel;
        this.tires = tires;
    }
}

工厂

将各个部分组合在一起以形成一个完整的对象，并对调用者隐藏具体类型。

static class CarFactory
{
    public ICar BuildCar()
    {
        Engine engine = new Engine();
        SteeringWheel steeringWheel = new SteeringWheel();
        Tires tires = new Tires();
        ICar car = new RaceCar(engine, steeringWheel, tires);
        return car;
    }   
}

结果

正如你所看到的，工厂和DI是相辅相成的。

static void Main()
{
     ICar car = CarFactory.BuildCar();
     // use car
}

你还记得金发姑娘和三只熊吗?依赖注入有点像这样。这里有三种方法来做同样的事情。

void RaceCar() // example #1
{
    ICar car = CarFactory.BuildCar();
    car.Race();
}

void RaceCar(ICarFactory carFactory) // example #2
{
    ICar car = carFactory.BuildCar();
    car.Race();
}

void RaceCar(ICar car) // example #3
{
    car.Race();
}

例#1——这是最糟糕的，因为它完全隐藏了依赖关系。如果你把这个方法看作一个黑盒子，你就不会知道它需要一辆车。

例2——这样会好一点，因为我们经过了一家汽车厂，现在我们知道我们需要一辆车。但是这次我们传递的太多了，因为这个方法实际上只需要一个car。我们正在路过一个工厂，只是为了建造汽车，当汽车可以在外面建造的方法和通过。

示例#3—这是理想的，因为该方法要求的正是它所需要的。不要太多也不要太少。我不需要为了创建MockCars而编写MockCarFactory，我可以直接传入mock。它是直接的，界面不会说谎。

Misko Hevery的谷歌技术演讲非常棒，这是我得到我的例子的基础。http://www.youtube.com/watch?v=XcT4yYu_TTs