我想给你在乘坐地铁或等公交车时3-5分钟的学习片段。一点点就会产生很大的差异。感谢您的关注。
从UML来理解依赖
1.1 什么是依赖？
首先我们来看看下面这张照片
HomeController 类使用了DBContext 类，虽然这种关系是随意的、临时的、弱的，但很容易理解DBContext 的更改会影响HomeController。
1.2 显式和隐式依赖
首先，看一下所示的依赖代码。
查看依赖关系可以通过其构造函数清楚地说明HomeController 类依赖于哪些对象，以便您可以更好地管理这些依赖关系。隐式依赖的缺点正是显式依赖的优点。让我们看一下以下隐式依赖关系：
如果你的类中有上千行代码，而且这种代码到处嵌入，这些代码就像是隐藏的病毒，可想而知后续的改动和修改会有多可怕。
1.3 依赖倒置
依赖倒置的概念其实很简单，几句话就可以概括。这意味着“你需要依赖抽象而不是具体的实现”。什么是抽象？示例包括接口和抽象类。
依赖抽象的目的是什么？因为实现接口的所有实现都是可以互换的。
如上图所示，如果从数据库DapperUserRepository 切换到EfUserRepository，HomeController 类可以平滑切换，无需进行任何更改。相反，变化的幅度是非常大的。
如果你看下面的代码，OrderController对接口IUserRepository的依赖就是依赖倒置的表现。
从单元测试来理解
你可能会说，我的改变并不那么频繁，所以我不需要那么麻烦。您是否考虑过可能需要对代码进行单元测试？如果可能，您应该进行依赖项注入。
2.1 控制反转
我们来看看下面代码中的问题
OrderController依赖于一个满足依赖倒置原则的接口IUserRepository，但是它的构造函数依赖于一个具体的实现类UserRepository。这种方法是硬编码的，无法适应未来变化引入的变化。接下来，我们将讨论控制反转这个相对难以捉摸的概念。
首先我们来谈谈逆转。可以看到构造函数内生成了OrderController依赖的对象UserRepository。如何将对象的生成留给外部实体来确定生成？明白了！这种转移对象生成的方法称为控制反转。
也就是说，反转的是控制，即由依赖对象产生的控制。您决定自己生成还是让其他人生成？
那么上面的代码就修改为：
上面的代码实现了真正的控制反转。 UserRepository 对象的生成完全是外部的并且通过修改来控制。
这样做的好处是什么？交给外部生成的最大好处是你可以完全控制生成的对象，这样你以后就可以轻松地创建对象，比如更改数据库访问对象或替换其实现类。单元测试是可以替换的。
这里，我借用大内老A的一句话作为总结。所谓控制反转，就是将相应进程的控制权转移给框架。这体现的是控制权的转移。也就是说，原来的控制权在A手中，但现在B必须接管。 IoC中包含的所谓控制，可以理解为“对进程的控制”。
2.2 单元测试
通过上述控制反转，单元测试有很多方面。
如果无法连接到数据库，您可以使用MemoryUserRepository 来替换单元测试，您会发现它非常有用。
我是来自IT的张飞鸿。我在这个行业已经工作了十多年了，我的快乐始终如一。
#3.1 依赖注入以上《ASP.NET Core系列简介》相关内容来自源码网络，仅供参考。相关信息请参见官方公告。
原创文章，作者：CSDN，如若转载，请注明出处：https://www.sudun.com/ask/92620.html
