依赖注入

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

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

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

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

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

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

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

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

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

依赖注入的一个缺点是它不能用逻辑初始化对象。例如，当我需要创建一个随机名称和年龄的字符时，DI不是工厂模式的选择。使用工厂，我们可以很容易地从对象创建中封装随机算法，它支持一种称为“封装变化”的设计模式。

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

使用依赖注入框架，开发人员不需要手动准备和设置类实例的依赖项，这一切都是事先准备好的。

对于工厂，开发人员必须手工完成，并使用这些依赖对象创建类实例。

区别主要在于这一行中调用工厂并获取构造的对象，以及编写工厂方法来创建和设置所有内容(尽管可以认为，在依赖注入框架中，通过连接和配置对象关系，这也必须在一定程度上完成)。

如果是工厂，你就得打电话给任何需要这种东西的工厂。 使用依赖注入框架，你可以在类实例创建时依赖对象的存在。

我的观点是，工厂方法更静态，因为它的实现相当固定，而依赖注入框架更动态，因为类实例的实际组合更容易改变(例如。为了测试目的)在运行时。

依赖注入(DI)和工厂模式相似的原因是它们是控制反转(IoC)的两种实现，IoC是一种软件架构。简单地说，它们是同一问题的两种解决方案。

因此，为了回答这个问题，工厂模式和依赖注入模式之间的主要区别在于如何获得对象引用。依赖项注入顾名思义就是将引用注入或提供给您的代码。使用工厂模式，您的代码必须请求引用，以便您的代码获取对象。这两种实现都删除或解耦了代码与所使用的对象引用的底层类或类型之间的链接。

值得注意的是，工厂模式(或者实际上是抽象工厂模式，即返回返回对象引用的新工厂的工厂)可以被编写为在运行时动态地选择或链接到被请求的对象类型或类。这使得它们与服务定位器模式非常相似(甚至比DI更相似)，后者是IoC的另一个实现。

工厂设计模式相当古老(就软件而言)，并且已经存在了一段时间。由于IoC体系结构模式最近的流行，它正在复苏。

我想当涉及到IoC设计模式时:注入器被注入，定位器被定位，工厂被重构。