依赖注入

依赖注入（DI）的重点是减少代码耦合。想象一下任何类型的交互都涉及到新的东西，如硬编码依赖示例。

编写代码的很大一部分是测试它的能力。每次我们新建一个新的依赖项时，我们都会使代码难以测试，因为我们无法控制该依赖项。

你将如何测试依赖于 DataTime.Now 的代码？它总是会改变，所以你没有参考。这是当你注入稳定参数作为起点时。你可以控制它，你可以根据各种值编写测试，并确保始终获得正确的结果。

因此，一个好的选择是将接口或抽象类作为参数传递给构造函数 DI。

接口表示定义良好的合同，你始终可以依赖方法，并且始终可以依赖方法签名。

一旦开始使用 DI，其他方面将会打开。例如，即使你在某个时刻传递了一个接口，你也需要一个真正的实现才能真正完成任何工作。这是其他概念出现的地方。我们可以使用 IOC（控制反转）来解决我们的依赖关系。这意味着我们指示我们的代码始终使用任何合同的特定实现。当然还有其他方法可以做到这一点。我们总是可以使用特定的实现来实例化每个合同，从那时起我们的代码就可以使用该部分：

public ILogging Logging { get; set }

在某些时候我们初始化它。

Logging = new FileLogging();

只要我们的类达到预期的合同，这将始终有效：

public class FileLogging : ILogging

从初始阶段开始，我们总是使用 Logging 对象。这使生命更容易，因为如果我们决定更改和使用 DatabaseLogging，我们只需要在一个地方更改代码，这正是我们初始化 Logging 类的地方。

DI 只适合测试吗？不，在编写可维护代码时，DI 也很重要。它可以清楚地分离关注点。

当你编写任何代码时，请认为……是可测试的，我可以编写测试，这是在注入 DateTime 值而不是使用 DateTime 时。这是有道理的。