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

DI是真实对象之间实际交互的方式，而不需要一个对象负责另一个对象的存在。应平等对待对象。它们都是对象。任何人都不应该表现得像一个创造者。这就是你如何公正对待你的目标。

简单示例：

如果你需要医生，你只需去找一位（现有的）医生。你不会考虑从头开始创建一个医生来帮助你。他已经存在，他可能为你或其他对象服务。无论你（一个物体）是否需要他，他都有权存在，因为他的目的是为一个或多个物体服务。决定他的存在的是全能的上帝，而不是自然选择。因此，DI的一个优点是避免在整个宇宙（即应用程序）的生命周期中创建无用的冗余对象。

简单来说，依赖注入（DI）是消除不同对象之间的依赖关系或紧密耦合的方法。依赖注入为每个对象提供一个内聚行为。

DI是国际奥委会春季原则的实施，该原则说“不要打电话给我们，我们会打电话给你”。使用依赖注入程序员不需要使用new关键字创建对象。

对象一旦加载到Spring容器中，我们就可以在需要时重用它们，方法是使用getBean（StringbeanName）方法从Spring容器中获取这些对象。

我想既然每个人都为DI写过文章，让我问几个问题。。

当您有一个DI配置，其中所有实际实现（而不是接口）都将被注入到一个类中（例如控制器的服务），为什么这不是某种硬编码？如果我想在运行时更改对象怎么办？例如，我的配置已经表明，当我实例化MyController时，为FileLogger注入ILogger。但我可能想注入DatabaseLogger。每次我想更改AClass需要的对象时，我都需要查看两个地方——类本身和配置文件。这是如何让生活更轻松的？如果没有注入Aproperty的AClass，是否更难模拟？回到第一个问题。如果使用new object（）不好，我们为什么要注入实现而不是接口？我想你们很多人都在说我们实际上是在注入接口，但配置要求您指定接口的实现。。不在运行时。。它在编译时是硬编码的。

这是基于@Adam N发布的答案。

为什么PersonService不再需要担心GroupMembershipService？您刚才提到了GroupMembership依赖于多个东西（对象/财产）。如果PService中需要GMService，您应该将其作为属性。不管你是否注射，你都可以模仿它。我唯一希望它被注入的时候是GMService是否有更具体的子类，这在运行时之前你不会知道。然后您需要注入子类。或者如果您想将其用作单例或原型。老实说，配置文件中的所有内容都是硬编码的，包括它将在编译时为类型（接口）注入的子类。

编辑

Jose Maria Arranz对DI的美好评论

DI通过消除确定依赖方向和编写任何粘合代码的任何需要来提高内聚性。

错误。依赖关系的方向是XML形式或注释，依赖关系是以XML代码和注释的形式编写的。XML和注释是源代码。

DI通过使您的所有组件模块化（即可更换）并具有相互定义良好的接口来减少耦合。

错误。您不需要DI框架来构建基于接口的模块化代码。

关于可替换：使用非常简单的.properties存档和Class.forName，您可以定义哪些类可以更改。如果代码的任何类都可以更改，Java不适合您，请使用脚本语言。顺便说一句：不重新编译就不能更改注释。

在我看来，DI框架只有一个原因：锅炉板减少。有了一个做得好的工厂系统，您可以像首选的DI框架一样做得更好、更可控、更可预测，DI框架可以减少代码（XML和注释也是源代码）。问题是这种锅炉板减少在非常简单的情况下是真实的（每个类一个实例以及类似的情况），有时在现实世界中，选择适当的服务对象不像将类映射到单个对象那样容易。

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

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

什么是依赖注入（DI）？

正如其他人所说，依赖注入（DI）消除了直接创建和管理我们感兴趣的类（消费者类）所依赖的其他对象实例（在UML意义上）的生命周期的责任。这些实例通常作为构造函数参数或通过属性设置器传递给我们的消费者类（依赖对象实例化和传递给消费者类的管理通常由控制反转（IoC）容器执行，但这是另一个主题）。

DI、DIP和固体

具体来说，在Robert C Martin的面向对象设计的SOLID原则的范例中，DI是依赖反转原则（DIP）的可能实现之一。DIP是SOLID咒语的D——其他DIP实现包括服务定位器和插件模式。

DIP的目标是解耦类之间紧密、具体的依赖关系，相反，通过抽象来放松耦合，这可以通过接口、抽象类或纯虚拟类来实现，具体取决于所使用的语言和方法。

如果没有DIP，我们的代码（我称之为“消费类”）直接耦合到一个具体的依赖项，并且经常承担着知道如何获取和管理该依赖项实例的责任，即概念上：

"I need to create/use a Foo and invoke method `GetBar()`"

然而，在应用DIP后，这一要求被放宽，获得和管理Foo依赖寿命的担忧已经消除：

"I need to invoke something which offers `GetBar()`"

为什么使用DIP（和DI）？

以这种方式解耦类之间的依赖性允许用其他实现轻松替换这些依赖性类，这些实现也满足抽象的前提条件（例如，依赖性可以与同一接口的另一个实现切换）。此外，正如其他人所提到的，通过DIP解耦类的最常见原因可能是允许单独测试消费类，因为这些依赖关系现在可以被清除和/或嘲笑。

DI的一个结果是依赖对象实例的寿命管理不再由消费类控制，因为依赖对象现在被传递到消费类（通过构造函数或setter注入）。

这可以用不同的方式来看待：

如果需要保留消费类对依赖项的生命周期控制，则可以通过将用于创建依赖类实例的（抽象）工厂注入消费类来重新建立控制。消费者将能够根据需要通过工厂上的Create获取实例，并在完成后处理这些实例。或者，依赖实例的生命周期控制可以放弃给IoC容器（下面将详细介绍）。

何时使用DI？

在可能需要用依赖性替代等效实现的情况下，任何时候，如果您需要对类的方法进行单元测试，依赖项的生命周期的不确定性可能需要进行实验（例如，嘿，MyDepClass是线程安全的-如果我们将其设置为单例并将同一实例注入所有消费者，会怎么样？）

实例

这里是一个简单的C#实现。给定以下消费类：

public class MyLogger
{
   public void LogRecord(string somethingToLog)
   {
      Console.WriteLine("{0:HH:mm:ss} - {1}", DateTime.Now, somethingToLog);
   }
}

虽然看似无害，但它对另外两个类System.DateTime和System.Console有两个静态依赖关系，这不仅限制了日志输出选项（如果没有人在监视，则日志记录到控制台将毫无价值），而且更糟糕的是，考虑到对非确定性系统时钟的依赖关系，很难自动测试。

然而，我们可以将DIP应用于这个类，方法是将时间戳问题抽象为依赖项，并将MyLogger仅耦合到一个简单的接口：

public interface IClock
{
    DateTime Now { get; }
}

我们还可以将对Console的依赖放宽为抽象，例如TextWriter。依赖注入通常实现为构造函数注入（将抽象作为参数传递给依赖项作为消费类的构造函数）或Setter注入（通过setXyz（）Setter或定义了{set；}的.Net Property传递依赖项）。构造函数注入是首选的，因为这样可以保证类在构造后处于正确的状态，并允许将内部依赖字段标记为只读（C#）或最终（Java）。因此，在上面的示例中使用构造函数注入，这就给我们留下了：

public class MyLogger : ILogger // Others will depend on our logger.
{
    private readonly TextWriter _output;
    private readonly IClock _clock;

    // Dependencies are injected through the constructor
    public MyLogger(TextWriter stream, IClock clock)
    {
        _output = stream;
        _clock = clock;
    }

    public void LogRecord(string somethingToLog)
    {
        // We can now use our dependencies through the abstraction 
        // and without knowledge of the lifespans of the dependencies
        _output.Write("{0:yyyy-MM-dd HH:mm:ss} - {1}", _clock.Now, somethingToLog);
    }
}

（需要提供一个具体的Clock，它当然可以恢复到DateTime。现在，这两个依赖关系需要由IoC容器通过构造函数注入提供）

可以构建一个自动化的单元测试，这无疑证明了我们的记录器工作正常，因为我们现在可以控制依赖关系-时间，我们可以监视书面输出：

[Test]
public void LoggingMustRecordAllInformationAndStampTheTime()
{
    // Arrange
    var mockClock = new Mock<IClock>();
    mockClock.Setup(c => c.Now).Returns(new DateTime(2015, 4, 11, 12, 31, 45));
    var fakeConsole = new StringWriter();

    // Act
    new MyLogger(fakeConsole, mockClock.Object)
        .LogRecord("Foo");

    // Assert
    Assert.AreEqual("2015-04-11 12:31:45 - Foo", fakeConsole.ToString());
}

下一步

依赖注入总是与控制反转容器（IoC）相关联，以注入（提供）具体的依赖实例，并管理生命周期实例。在配置/引导过程中，IoC容器允许定义以下内容：

每个抽象和配置的具体实现之间的映射（例如“消费者请求IBar时，返回ConcreteBar实例”）可以为每个依赖项的生命周期管理设置策略，例如为每个消费者实例创建新对象，在所有消费者之间共享单一依赖项实例，仅在同一线程之间共享同一依赖项实例等。在.Net中，IoC容器了解IDisposable等协议，并将根据配置的生命周期管理来负责处理依赖关系。

通常，一旦IoC容器被配置/引导，它们就可以在后台无缝地运行，从而让编码器专注于手头的代码，而不用担心依赖性。

DI友好代码的关键是避免类的静态耦合，并且不要使用new（）创建依赖项

根据上面的示例，依赖关系的解耦确实需要一些设计工作，对于开发人员来说，需要进行范式转换，以打破直接添加依赖关系的习惯，转而信任容器来管理依赖关系。

但好处很多，特别是能够彻底测试你感兴趣的班级。

注意：POCO/POJO/Serialization DTO/Entity Graphs/Anonymous JSON投影等（即“仅数据”类或记录）的创建/映射/投影（通过新的..（））不被视为依赖项（在UML意义上），也不受DI的约束。使用new来投射这些是很好的。