什么是依赖注入（DI）？
就像其他人所说的，依赖注入（DI）消除了我们感兴趣的类（消费者类）所依赖的其他对象实例（在UML意义上）直接创建和寿命管理的责任。这些实例通常作为构造函数参数或通过属性设置器传递给我们的消费者类（对依赖对象实例化和传递给消费者类的管理通常由控制反转（IoC）容器执行，但这是另一个主题） 。
DI，DIP和SOLID
具体而言，在罗伯特·Ç马丁的范式面向对象设计的SOLID原则，DI为可能的实现方式之一依赖倒置原则（DIP） 。所述DIP是D所述的SOLID咒语 -其他DIP实现包括了服务定位器，和插件图案。
拨码的目标是类之间对紧解耦，混凝土的依赖关系，而代之以由一个抽象，其可以通过一个来实现的装置松开联接interface，abstract class或者pure virtual class，取决于所使用的语言和方法。
如果没有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);
}
}
虽然看似无害的，它有两个static其他两个类，依赖性System.DateTime和System.Console，这不仅限制了记录输出选项（记录到控制台将毫无价值，如果没有人看），但糟糕的是，它是很难自动测试给出的依赖一个不确定的系统时钟。
但是，我们可以DIP通过将时间戳记作为依赖项的关注抽象出来，并MyLogger仅耦合到简单的接口来应用于此类：
public interface IClock
{
DateTime Now { get; }
}
我们还可以放宽对Console抽象的依赖，例如TextWriter。依赖项注入通常实现为constructor注入（将依赖项的抽象作为消费类的构造函数的参数Setter Injection传递给依赖项）或（通过setXyz()设置器或带有{set;}定义的.Net属性传递依赖项）。最好使用构造函数注入，因为这样可以确保在构造后类将处于正确的状态，并允许将内部依赖项字段标记为readonly（C＃）或final（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.Now，并且两个依赖关系需要由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，并将根据Disposing已配置的寿命管理来承担依赖项的责任。
通常，一旦IoC容器已配置/自举，它们将在后台无缝运行，从而使编码人员可以专注于手头的代码，而不必担心依赖关系。
DI友好代码的关键是避免类的静态耦合，而不是使用new（）创建依赖项
如上面的示例所示，依赖关系的分离确实需要一些设计工作，并且对于开发人员而言，需要进行范式转换，以打破new直接使用依赖关系的习惯，而是信任容器来管理依赖关系。
但是好处很多，尤其是能够全面测试您感兴趣的课程。
注意：new ..()POCO / POJO /序列化DTO /实体图/匿名JSON投影等的创建/映射/投影（通过）-即“仅数据”类或记录-从方法使用或返回的方法不视为依赖项（在UML意义上的），并且不受DI约束。利用new项目，这些仅仅是罚款。
