写在前面：我之前写过一系列关于.NET Core依赖注入的文章，由于.NET Core依赖注入框架的实现原理发生了很大的改变，加上我对包括IoC和DI这些理论层面的东西又有了一些新的理解，所以我在此基础上写了8篇文章详细介绍.NET Core的DI。我将这些文章发布到我的微信公众账号（大内老A）下，很多人留言说还是博客具有更好的阅读体验，所以我将在未来8天时间将它们同步到这里。
软件设计中由一些所谓的理念都没有一个明确的定义，比如之前流行的SOA和现在炒的火热的微服务（Micro Service）和无服务器（Serverless），我们都不能通过一个明确的“内涵”给它们一个准确地定义，只能从“外延”上描述这些架构设计应该具有怎样的特性。正因为无法给出一个明确的界定，造成了人们针对同一个概念出现了很多不同的理解。针对IoC也是这种情况，所以本章所诉的仅仅代表作者的一家之言，读者朋友姑妄听之，仅作参考。
一、流程控制的反转我听到很多人将IoC说成是一种“面向对象的设计模式”，但在我个人看来IoC不能算作 一种“设计模式”，其自身也与“面向对象”没有直接的关系。我觉得很多人之所以不能很准确地理解IoC源于他们忽略了一个最根本的东西，那就是IoC这个短语，也就是他们之所以对IoC产生了诸多误解是因为他们忽略了IoC的定义。
IoC的全名Inverse of Control，翻译成中文就是“控制反转”或者“控制倒置”。控制反转也好，控制倒置也罢，它体现的意思是控制权的转移，即原来控制权在A手中，现在需要B来接管。那么具体对于软件设计来说，IoC所谓的控制权的转移具有怎样的体现呢？要回答这个问题，就需要先了解IoC的C（Control）究竟指的是怎样一种控制。对于我们所在的任何一件事，不论其大小，其实可以分解成相应的步骤，所以任何一件事都有其固有的流程，IoC涉及的所谓控制可以理解为“针对流程的控制”。
我们通过一个具体事例来说明传统的设计在采用了IoC之后针对流程的控制是如何实现反转的。比如说现在设计一个针对Web的MVC类库，我们不妨将其命名为MvcLib。简单起见，这个类库中只包含如下这个同名的静态类。
public static class MvcLib { public static Task ListenAsync(Uri address); public static Task<Request> ReceiveAsync(); public static Task<Controller> CreateControllerAsync(Request request); public static Task<View> ExecuteControllerAsync(Controller controller); public static Task RenderViewAsync(View view); }