ASP.NET Core在启动以及后续针对每个请求的处理过程中的各个环节都需要相应的组件提供相应的服务，为了方便对这些组件进行定制，ASP.NET通过定义接口的方式对它们进行了“标准化”，我们将这些标准化的组件称为服务，ASP.NET在内部专门维护了一个DI容器来提供所需的服务。要了解这个DI容器以及现实其中的服务提供机制，我们先得知道什么是DI（Dependence Injection），而一旦我们提到DI，又不得不说IoC（Inverse of Control）。
一、流程控制的反转
我听到很多人将IoC说成是一种“面向对象的设计模式”，但在我个人看来IoC不能算作一种“设计模式”，其自身也与“面向对象”没有直接的关系。很多人之所以不能很准确地理解IoC源于他们忽略了一个最根本的东西，那就是IoC这个短语。换句话说，很多人之所以对IoC产生了诸多误解是因为他们忽略了IoC的定义。
IoC的全名Inverse of Control，翻译成中文就是“控制反转”或者“控制倒置”。控制反转也好，控制倒置也罢，它体现的意思是控制权的转移，即原来控制权在A手中，现在需要B来接管。那么具体对于软件设计来说，IoC所谓的控制权的转移具有怎样的体现呢？要回答这个问题，就需要先了解IoC的C（Control）究竟指的是怎样一种控制，在我看来这里所谓的控制更多地体现为一种“流程的控制”。
我们通过一个具体事例来说明传统的设计在采用了IoC之后针对流程的控制是如何实现反转的。比如说我们现在设计一个针对Web的MVC类库，不妨将其命名为MvcLib。MvcLib提供了如下所示的API帮助我们完成整个HTTP请求流程中的主要任务。具体来说，ListenAndReceiveRequest方法启动一个监听器绑定到指定的地址进行请求的监听，接收到的请求通过一个Request对象返回。ActivateController方法根据接收到的请求解析并激活请求的目标Controller。ExecuteContrller方法执行激活的Controller并返回一个表示视图的View对象。RenderView最终将View对象转换成HTML并作为当前请求响应的内容。
public static class MvcLib { public static Request ListenAndReceiveRequest(Uri address); public static Controller ActivateController (Request request); public static View ExecuteContrller(Controller controller); public static void RenderView(View view); }
现在我们在这个MvcLib的基础上创建一个真正的MVC应用，那么除了按照MvcLib的规范自定义具体的Controller和View之外，我们还需要自行控制从请求的监听与接收、Controller的激活与执行以及View的最终呈现在内的整个流程，这样一个执行流程反映在如下所示的代码中。
public class App { static void Main(string[] args) { Uri address = new Uri("http://localhost/mvcapp"); while (true) { Request request = MvcLib.ListenAndReceiveRequest(address); Task.Run(()=> ProcessRequest(request)); } } private static void ProcessRequest(Request request) { Controller controller = MvcLib.ActiveController(request); View view = MvcLib.ExecuteContrller(controller); MvcLib.RenderView(view); } }
这个例子体现了右如图所示的流程控制方式，即我们设计的类库（MvcLib）仅仅通过API的形式提供某种单一功能的实现，作为类库消费者的应用程序（App）则需要自行编排整个工作流程。如果从重用的角度来讲，这里被重用的仅限于实现某个环节单一功能的代码，编排整个工作流程的代码并没有得到重用。
当我们构建一个应用的时候，我们不仅仅是需要一个能够提供API的类库，实际上更理想的形式是直接在一个现有的框架上构架我们的应用。类库（Library）和框架（Framework）的不同之处在于，前者往往只是提供实现某种单一功能的API，而后者则针对一个目标任务对这些单一功能进行编排形成一个完整的流程，这个流程在一个引擎的驱动下被执行。
在我们上面演示MvcLib来说，使用它的应用程序需要自行控制整个HTTP请求的处理流程，实际上这是一个很“泛化”的工作流程，几乎所有的MVC应用均采用这样的流程监听、接收请求并最终对请求予以响应。如果我们将这个流程实现在一个MVC框架之中，由它构建的所有MVC应用就可以直接使用这个请求处理流程，而并不需要自行重复实现它。
