针对5岁儿童的依赖注入。

当你自己去把冰箱里的东西拿出来时，你可能会引起问题。你可能会让门开着，你可能会得到妈妈或爸爸不希望你拥有的东西。你甚至可能在寻找我们甚至没有或已经过期的东西。

你应该做的是陈述一个需要，“我需要午餐时喝点东西”，然后我们会确保你坐下吃饭时有东西。

依赖注入是一种实践，其中对象的设计方式是从其他代码段接收对象实例，而不是在内部构造它们。这意味着可以在不更改代码的情况下替换实现对象所需接口的任何对象，这简化了测试，并改进了去耦。

例如，考虑这些类：

public class PersonService {
  public void addManager( Person employee, Person newManager ) { ... }
  public void removeManager( Person employee, Person oldManager ) { ... }
  public Group getGroupByManager( Person manager ) { ... }
}

public class GroupMembershipService() {
  public void addPersonToGroup( Person person, Group group ) { ... }
  public void removePersonFromGroup( Person person, Group group ) { ... }
} 

在本例中，PersonService:：addManager和PersonService：：removeManager的实现需要GroupMembershipService的实例才能完成其工作。如果没有依赖注入，传统的方法是在PersonService的构造函数中实例化一个新的GroupMembershipService，并在两个函数中使用该实例属性。但是，如果GroupMembershipService的构造函数有多个它需要的东西，或者更糟的是，需要在GroupMembershipServices上调用一些初始化“setter”，代码增长相当快，PersonService现在不仅依赖于GroupMembershipService，还依赖于GroupMembershipService所依赖的所有其他东西。此外，与GroupMembershipService的链接被硬编码到PersonService中，这意味着您不能为了测试目的而“虚拟”GroupMembershipServices，或者在应用程序的不同部分使用策略模式。

使用依赖注入，而不是在PersonService中实例化GroupMembershipService，您可以将其传递给PersonService构造函数，或者添加Property（getter和setter）来设置其本地实例，并与他们合作。这也意味着，任何属于GroupMembershipService的子类或实现GroupMembershipServices接口的内容都可以“注入”到PersonService中，PersonService不需要知道更改。

摘自《扎实的Java开发人员：Java 7和多语言编程的关键技术》一书

DI是IoC的一种特殊形式，因此查找依赖项的过程是不受当前执行代码的直接控制。

让我们用Car和Engine类来尝试一个简单的例子，任何汽车都需要一个引擎，至少目前是这样。下面是没有依赖注入的代码的外观。

public class Car
{
    public Car()
    {
        GasEngine engine = new GasEngine();
        engine.Start();
    }
}

public class GasEngine
{
    public void Start()
    {
        Console.WriteLine("I use gas as my fuel!");
    }
}

为了实例化Car类，我们将使用以下代码：

Car car = new Car();

这个代码的问题是我们与GasEngine紧密耦合，如果我们决定将其更改为ElectricityEngine，那么我们需要重写Car类。应用程序越大，我们必须添加和使用新型引擎的问题和麻烦就越多。

换句话说，这种方法是我们的高级Car类依赖于低级GasEngine类，这违反了SOLID的依赖反转原理（DIP）。DIP建议我们应该依赖抽象，而不是具体的类。因此，为了满足这一点，我们引入了IEngine接口并重写如下代码：

    public interface IEngine
    {
        void Start();
    }

    public class GasEngine : IEngine
    {
        public void Start()
        {
            Console.WriteLine("I use gas as my fuel!");
        }
    }

    public class ElectricityEngine : IEngine
    {
        public void Start()
        {
            Console.WriteLine("I am electrocar");
        }
    }

    public class Car
    {
        private readonly IEngine _engine;
        public Car(IEngine engine)
        {
            _engine = engine;
        }

        public void Run()
        {
            _engine.Start();
        }
    }

现在我们的Car类只依赖于IEngine接口，而不是引擎的特定实现。现在，唯一的诀窍是我们如何创建Car的实例，并给它一个实际的具体Engine类，比如GasEngine或ElectricityEngine。这就是依赖注入的作用。

   Car gasCar = new Car(new GasEngine());
   gasCar.Run();
   Car electroCar = new Car(new ElectricityEngine());
   electroCar.Run();

在这里，我们基本上将依赖项（Engine实例）注入（传递）到Car构造函数。因此，现在我们的类在对象及其依赖关系之间具有松散的耦合，我们可以在不更改Car类的情况下轻松添加新类型的引擎。

依赖注入的主要好处是类之间的耦合更加松散，因为它们没有硬编码的依赖关系。这遵循了上面提到的依赖反转原则。类不是引用特定的实现，而是请求抽象（通常是接口），这些抽象是在构造类时提供给它们的。

所以最终依赖注入只是一种技术实现对象及其依赖关系之间的松散耦合。而不是直接实例化类需要的依赖项为了执行其操作，向类提供依赖项（通常）通过构造函数注入。

此外，当我们有很多依赖项时，使用控制反转（IoC）容器是非常好的做法，我们可以告诉哪些接口应该映射到我们所有依赖项的具体实现，我们可以让它在构建对象时为我们解决这些依赖项。例如，我们可以在IoC容器的映射中指定IEngine依赖项应映射到GasEngine类，当我们向IoC容器请求Car类的实例时，它将自动构建Car类，并传入GasEngine依赖项。

更新：最近观看了Julie Lerman关于EF Core的课程，也喜欢她对DI的简短定义。

依赖注入是一种允许应用程序注入的模式对象，而无需强制类来负责这些对象。它允许您的代码更松散的耦合，并且实体框架核心插入到该框架中服务体系。

使依赖注入概念易于理解。让我们以开关按钮为例来切换（打开/关闭）灯泡。

无依赖注入

Switch需要事先知道我连接到哪个灯泡（硬编码依赖项）。所以

开关->永久灯泡//开关直接连接到永久灯泡，测试不容易

Switch(){
PermanentBulb = new Bulb();
PermanentBulb.Toggle();
}

使用依赖注入

开关只知道我需要打开/关闭传递给我的灯泡。所以，

开关->灯泡1或灯泡2或夜灯泡（注入依赖性）

Switch(AnyBulb){ //pass it whichever bulb you like
AnyBulb.Toggle();
}

修改开关和灯泡的James示例：

public class SwitchTest { 
  TestToggleBulb() { 
    MockBulb mockbulb = new MockBulb(); 

    // MockBulb is a subclass of Bulb, so we can 
    // "inject" it here: 
    Switch switch = new Switch(mockBulb); 

    switch.ToggleBulb(); 
    mockBulb.AssertToggleWasCalled(); 
  } 
}

public class Switch { 
  private Bulb myBulb; 

  public Switch() { 
    myBulb = new Bulb(); 
  } 

  public Switch(Bulb useThisBulbInstead) { 
    myBulb = useThisBulbInstead; 
  } 

  public void ToggleBulb() { 
    ... 
    myBulb.Toggle(); 
    ... 
  } 
}`

依赖注入（DI）是依赖反转原理（DIP）实践的一部分，也称为控制反转（IoC）。基本上，你需要做DIP，因为你想让你的代码更加模块化和单元可测试，而不是仅仅一个单片系统。因此，您开始识别可以从类中分离并抽象出来的代码部分。现在抽象的实现需要从类外部注入。通常这可以通过构造函数完成。因此，您创建了一个构造函数，它接受抽象作为参数，这称为依赖注入（通过构造函数）。有关DIP、DI和IoC容器的更多说明，请阅读此处