来自Christoffer Noring，Pablo Deeleman的书《学习角度-第二版》：

“随着我们的应用程序的增长和发展，我们的每一个代码实体都将在内部需要其他对象的实例，在软件工程领域中，这些对象被称为依赖关系。将这些依赖关系传递给依赖客户端的动作被称为注入，它还需要另一个代码主体（称为注入器）的参与。注入器将负责用于实例化和引导所需依赖项的功能，以便它们从成功注入客户端的那一刻起就可以使用。这一点非常重要，因为客户机不知道如何实例化自己的依赖关系，只知道为了使用它们而实现的接口。"

发件人：Anton Moiseev。《字体角度发展，第二版》一书：

“简而言之，DI帮助您以松散耦合的方式编写代码，并使代码更易于测试和重用。”

依赖注入是将依赖传递给其他对象或框架（依赖注入器）。

依赖注入使测试更容易。注入可以通过构造函数完成。

SomeClass（）的构造函数如下：

public SomeClass() {
    myObject = Factory.getObject();
}

问题：如果myObject涉及诸如磁盘访问或网络访问之类的复杂任务，则很难在SomeClass（）上进行单元测试。程序员必须模拟myObject，并可能拦截工厂调用。

替代解决方案：

将myObject作为参数传入构造函数

public SomeClass (MyClass myObject) {
    this.myObject = myObject;
}

myObject可以直接传递，这使得测试更容易。

一种常见的替代方法是定义一个不做任何事情的构造函数。依赖注入可以通过setter完成。（h/t@MikeVella）。Martin Fowler记录了第三种选择（h/t@MarcDix），其中类显式地实现了程序员希望注入的依赖项的接口。

在没有依赖注入的情况下，很难在单元测试中隔离组件。

2013年，当我写下这个答案时，这是谷歌测试博客的一个主要主题。这对我来说仍然是最大的优势，因为程序员在运行时设计中并不总是需要额外的灵活性（例如，服务定位器或类似模式）。程序员通常需要在测试期间隔离类。

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

例如，考虑这些类：

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不需要知道更改。

让我们想象一下，你想去钓鱼：

没有依赖注入，你需要自己处理所有的事情。你需要找一艘船，买一根鱼竿，寻找诱饵等等。当然，这是可能的，但这给你带来了很多责任。在软件方面，这意味着你必须对所有这些东西进行查找。通过依赖注入，其他人负责所有准备工作，并为您提供所需的设备。你将收到（“被注射”）船、鱼竿和鱼饵——所有这些都准备好使用。

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

无依赖注入

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(); 
    ... 
  } 
}`

让我们用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的简短定义。

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