通过重建Hosting系统理解HTTP请求在ASP.NET Core管道中的处理流程[下]：管道是如何构建起来的？

在《中篇》中，我们对管道的构成以及它对请求的处理流程进行了详细介绍，接下来我们需要了解的是这样一个管道是如何被构建起来的。总的来说，管道由一个服务器和一个HttpApplication构成，前者负责监听请求并将接收的请求传递给给HttpApplication对象处理，后者则将请求处理任务委托给注册的中间件来完成。中间件的注册是通过ApplicationBuilder对象来完成的，所以我们先来了解一下这究竟是个怎样的对象。[本文已经同步到《ASP.NET Core框架揭秘》之中] [源代码从这里下载]

目录
一、ApplicationBuilder——用于注册中间件并创建管道
二、Startup——利用ApplicationBuilder注册中间件
三、作为宿主的WebHost和它的构建者

我们所说的ApplicationBuilder是对所有实现了IApplicationBuilder接口的所有类型及其对象的统称。用于创建WebHost的WebHostBuilder具有一个用于管道定值的Configure方法，它利用作为参数的ApplicationBuilder对象进行中间件的注册。由于ApplicationBuilder与组成管道的中间件具有直接的关系，所以我们得先来说说中间件在管道中究竟体现为一个怎样的对象。

中间件在请求处理流程中体现为一个类型为Func<RequestDelegate，RequestDelegate>的委托对象，对于很多刚刚接触请求处理管道的读者朋友们来说，可能一开始对此有点难以理解，所以容来略作解释。我们上面已经提到过RequestDelegate这么一个委托，它相当于一个Func<HttpContext, Task>对象，它象体现了针对HttpContext所进行的某项操作，实际上体现某个中间件针对请求的处理。那为何我们不直接用一个RequestDelegate对象来表示一个中间件，而将它表示成一个Func<RequestDelegate，RequestDelegate>对象呢？

在大部分应用中，我们会针对具体的请求处理需求注册多个不同的中间件，这些中间件按照注册时间的先后顺序进行排列进而构成管道。对于某个中间件来说，在它完成了自身的请求处理任务之后，需要将请求传递给下一个中间件作后续的处理。Func<RequestDelegate，RequestDelegate>中作为输入参数的RequestDelegate对象代表一个委托链，体现了后续中间件对请求的处理。一般来说，当某个中间件将自身实现的请求处理任务添加到这个委托链中，新的委托链将作为这个Func<RequestDelegate，RequestDelegate>对象的返回值。

以下图所示的管道为例，如果用一个Func<RequestDelegate，RequestDelegate>来表示中间件B，那么作为输入参数的RequestDelegate对象代表的是C对请求的处理操作，而返回值则代表B和C先后对请求处的处理操作。如果一个Func<RequestDelegate，RequestDelegate>代表第一个从服务器接收请求的中间件（比如A），那么执行该委托对象返回的RequestDelegate实际上体现了整个管道对请求的处理。

在对中间件有了充分的了解之后，我们来看看用于注册中间件的IApplicationBuilder接口的定义。如下所示的是经过裁剪后的IApplicationBuilder接口的定义，我们只保留了两个核心的方法，其中Use方法实现了针对中间件的注册，另一个Build方法则将所有注册的中间件转换成一个RequestDelegate对象。

interface IApplicationBuilder

   2: {

   3:     RequestDelegate Build();

   4:     IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);

   5: }