前言

最近打算抽時(shí)間看一下 ASP.NET Core MVC 的源碼，特此把自己學(xué)習(xí)到的內(nèi)容記錄下來，也算是做個(gè)筆記吧。

路由作為 MVC 的基本部分，所以在學(xué)習(xí) MVC 的其他源碼之前還是先學(xué)習(xí)一下路由系統(tǒng)，ASP.NET Core 的路由系統(tǒng)相對于以前的 Mvc 變化很大，它重新整合了 Web Api 和 MVC。

路由源碼地址 ：Routing-dev_jb51.rar

路由（Routing）功能介紹

路由是 MVC 的一個(gè)重要組成部分，它主要負(fù)責(zé)將接收到的 Http 請求映射到具體的一個(gè)路由處理程序上，在MVC 中也就是說路由到具體的某個(gè) Controller 的 Action 上。

路由的啟動方式是在ASP.NET Core MVC 應(yīng)用程序啟動的時(shí)候作為一個(gè)中間件來啟動的，詳細(xì)信息會在下一篇的文章中給出。

通俗的來說就是，路由從請求的 URL 地址中提取信息，然后根據(jù)這些信息進(jìn)行匹配，從而映射到具體的處理程序上，因此路由是基于URL構(gòu)建的一個(gè)中間件框架。
 路由還有一個(gè)作用是生成響應(yīng)的的URL，也就是說生成一個(gè)鏈接地址可以進(jìn)行重定向或者鏈接。

路由中間件主要包含以下幾個(gè)部分：

1. URL 匹配
2. URL 生成
3. IRouter 接口
4. 路由模板
5. 模板約束

Getting Started

ASP.NET Core Routing 主要分為兩個(gè)項(xiàng)目，分別是 Microsoft.AspNetCore.Routing.Abstractions,Microsoft.AspNetCore.Routing。前者是一個(gè)路由提供各功能的抽象，后者是具體實(shí)現(xiàn)。

我們在閱讀源碼的過程中，我建議還是先大致瀏覽一下項(xiàng)目結(jié)構(gòu)，然后找出關(guān)鍵類，再由入口程序進(jìn)行閱讀。

Microsoft.AspNetCore.Routing.Abstractions

大致看完整個(gè)結(jié)構(gòu)之后，我可能發(fā)現(xiàn)了幾個(gè)關(guān)鍵的接口，理解了這幾個(gè)接口的作用后能夠幫助我們在后續(xù)的閱讀中事半功倍。

IRouter

在 Microsoft.AspNetCore.Routing.Abstractions 中有一個(gè)關(guān)鍵的接口就是 IRouter:

public interface IRouter
{
 Task RouteAsync(RouteContext context);

 VirtualPathData GetVirtualPath(VirtualPathContext context);
}

這個(gè)接口主要干兩件事情，第一件是根據(jù)路由上下文來進(jìn)行路由處理，第二件是根據(jù)虛擬路徑上下文獲取 VirtualPathData。

IRouteHandler

另外一個(gè)關(guān)鍵接口是 IRouteHandler , 根據(jù)名字可以看出主要是對路由處理程序機(jī)型抽象以及定義的一個(gè)接口。

public interface IRouteHandler
{
 RequestDelegate GetRequestHandler(HttpContext httpContext, RouteData routeData);
}

它返回一個(gè) RequestDelegate 的一個(gè)委托，這個(gè)委托可能大家比較熟悉了，封裝了處理Http請求的方法，位于Microsoft.AspNetCore.Http.Abstractions 中，看過我之前博客的同學(xué)應(yīng)該比較了解。

這個(gè)接口中 GetRequestHandler 方法有兩個(gè)參數(shù)，第一個(gè)是 HttpContext，就不多說了，主要是來看一下第二個(gè)參數(shù) RouteData。

RouteData，封裝了當(dāng)前路由中的數(shù)據(jù)信息，它包含三個(gè)主要屬性，分別是 DataTokens, Routers, Values。

DataTokens： 是匹配的路徑中附帶的一些相關(guān)屬性的鍵值對字典。

Routers： 是一個(gè) Ilist<IRouter> 列表，說明RouteData 中可能會包含子路由。

Values： 當(dāng)前路由的路徑下包含的鍵值。

還有一個(gè) RouteValueDictionary, 它是一個(gè)集合類，主要是用來存放路由中的一些數(shù)據(jù)信息的，沒有直接使用 IEnumerable<KeyValuePair<string, string>> 這個(gè)數(shù)據(jù)結(jié)構(gòu)是應(yīng)為它的內(nèi)部存儲轉(zhuǎn)換比較復(fù)雜，它的構(gòu)造函數(shù)接收一個(gè) Object 的對象，它會嘗試將Object 對象轉(zhuǎn)化為自己可以識別的集合。

IRoutingFeature

我根據(jù)這個(gè)接口的命名一眼就看出來了這個(gè)接口的用途，還記得我在之前博客中講述Http管道流程中得時(shí)候提到過一個(gè)叫 工具箱 的東西么，這個(gè) IRoutingFeature 也是其中的一個(gè)組成部分。我們看一下它的定義：

public interface IRoutingFeature
{
 RouteData RouteData { get; set; }
}

原來他只是包裝了 RouteData，到 HttpContext 中啊。

IRouteConstraint

這個(gè)接口我在閱讀的時(shí)候看了一下注釋，原來路由中的參數(shù)參數(shù)檢查主要是靠這個(gè)接口來完成的。

我們都知道在我們寫一個(gè) Route Url地址表達(dá)式的時(shí)候，有時(shí)候會這樣寫：Route("/Product/{ProductId:long}") , 在這個(gè)表達(dá)式中有一個(gè) {ProductId:long} 的參數(shù)約束，那么它的主要功能實(shí)現(xiàn)就是靠這個(gè)接口來完成的。

/// Defines the contract that a class must implement in order to check whether a URL parameter
/// value is valid for a constraint.
public interface IRouteConstraint
{
 bool Match(
  HttpContext httpContext,
  IRouter route,
  string routeKey,
  RouteValueDictionary values,
  RouteDirection routeDirection);
}

Microsoft.AspNetCore.Routing

Microsoft.AspNetCore.Routing 主要是對 Abstractions 的一個(gè)主要實(shí)現(xiàn)，我們閱讀代碼的時(shí)候可以從它的入口開始閱讀。

RoutingServiceCollectionExtensions 是一個(gè)擴(kuò)展ASP.NET Core DI 的一個(gè)擴(kuò)展類，在這個(gè)方法中用來進(jìn)行 ConfigService，Routing 對外暴露了一個(gè) IRoutingBuilder 接口用來讓用戶添加自己的路由規(guī)則，我們來看一下：

public static IApplicationBuilder UseRouter(this IApplicationBuilder builder, Action<IRouteBuilder> action)
{
 //...略
 
 // 構(gòu)造一個(gè)RouterBuilder 提供給action委托宮配置
 var routeBuilder = new RouteBuilder(builder);
 action(routeBuilder);
 
 //調(diào)用下面的一個(gè)擴(kuò)展方法，routeBuilder.Build() 見下文
 return builder.UseRouter(routeBuilder.Build());
}

public static IApplicationBuilder UseRouter(this IApplicationBuilder builder, IRouter router)
{
  //...略
  
 return builder.UseMiddleware<RouterMiddleware>(router);
}

routeBuilder.Build() 構(gòu)建了一個(gè)集合 RouteCollection，用來保存所有的 IRouter 處理程序信息，包括用戶配置的Router。

RouteCollection 本身也實(shí)現(xiàn)了 IRouter , 所以它也具有路由處理的能力。

Routing 中間件的入口是 RouterMiddleware 這個(gè)類，通過這個(gè)中間件注冊到 Http 的管道處理流程中， ASP.NET Core MVC 會把它默認(rèn)的作為其配置項(xiàng)的一部分，當(dāng)然你也可以把Routing單獨(dú)拿出來使用。

我們來看一下 Invoke 方法里面做了什么，它位于RouterMiddleware.cs 文件中。

public async Task Invoke(HttpContext httpContext)
{
  var context = new RouteContext(httpContext);
  context.RouteData.Routers.Add(_router);

  await _router.RouteAsync(context);

  if (context.Handler == null)
  {
    _logger.RequestDidNotMatchRoutes();
    await _next.Invoke(httpContext);
  }
  else
  {
    httpContext.Features[typeof(IRoutingFeature)] = new RoutingFeature()
    {
      RouteData = context.RouteData,
    };

    await context.Handler(context.HttpContext);
  }
}

首先，通過 httpContext 來初始化路由上下文（RouteContext），然后把用戶配置的路由規(guī)則添加到路由上下文RouteData中的Routers中去。

接下來 await _router.RouteAsync(context) , 就是用到了 IRouter 接口中的 RouteAsync 方法了。

我們接著跟蹤 RouteAsync 這個(gè)函數(shù)，看其內(nèi)部都做了什么？ 我們又跟蹤到了RouteCollection.cs 這個(gè)類：

我們看一下 RouteAsync 的流程：

public async virtual Task RouteAsync(RouteContext context)
{
  var snapshot = context.RouteData.PushState(null, values: null, dataTokens: null);

  for (var i = 0; i < Count; i++)
  {
    var route = this[i];
    context.RouteData.Routers.Add(route);

    try
    {
      await route.RouteAsync(context);

      if (context.Handler != null)
      {
        break;
      }
    }
    finally
    {
      if (context.Handler == null)
      {
        snapshot.Restore();
      }
    }
  }
}

我覺得這個(gè)類，包括函數(shù)設(shè)計(jì)的很巧妙，如果是我的話，我不一定能夠想的出來，所以我們通過看源碼也能夠?qū)W到很多新知識。

為什么說設(shè)計(jì)的巧妙呢？ RouteCollection 繼承了 IRouter 但是并沒有具體的對路由進(jìn)行處理，而是通過循環(huán)來重新將路由上下文分發(fā)的具體的路由處理程序上。我們來看一下他的流程：

1、為了提高性能，創(chuàng)建了一個(gè)RouteDataSnapshot 快照對象，RouteDataSnapshot是一個(gè)結(jié)構(gòu)體，它存儲了 Route 中的路由數(shù)據(jù)信息。

2、循環(huán)當(dāng)前 RouteCollection 中的 Router，添加到 RouterContext里的Routers中，然后把RouterContext交給Router來處理。

3、當(dāng)沒有處理程序處理當(dāng)前路由 snapshot.Restore() 重新初始化快照狀態(tài)。

接下來就要看具體的路由處理對象了，我們從 RouteBase 開始。

1、RouteBase 的構(gòu)造函數(shù)會初始化 RouteTemplate, Name, DataTokens, Defaults.
 Defaults 是默認(rèn)配置的路由參數(shù)。

2、RouteAsync 中會進(jìn)行一系列檢查，如果沒有匹配到URL對應(yīng)的路由就會直接返回。

3、使用路由參數(shù)匹配器 RouteConstraintMatcher 進(jìn)行匹配，如果沒有匹配到，同樣直接返回。

4、如果匹配成功，會觸發(fā) OnRouteMatched(RouteContext context)函數(shù)，它是一個(gè)抽象函數(shù)，具體實(shí)現(xiàn)位于 Route.cs 中。

然后，我們再繼續(xù)跟蹤到 Route.cs 中的 OnRouteMatch，一起來看一下：

protected override Task OnRouteMatched(RouteContext context)
{
  
  context.RouteData.Routers.Add(_target);
  return _target.RouteAsync(context);
}

_target 值得當(dāng)前路由的處理程序，那么具體是哪個(gè)路由處理程序呢？ 我們一起探索一下。

我們知道，我們創(chuàng)建路由一共有MapRoute,MapGet,MapPost,MapPut,MapDelete,MapVerb... 等等這寫方式，我們分別對應(yīng)說一下每一種它的路由處理程序是怎么樣的，下面是一個(gè)示例：

app.UseRouter(routes =>{
  routes.DefaultHandler = new RouteHandler((httpContext) =>
  {
    var request = httpContext.Request;
    return httpContext.Response.WriteAsync($"");
  });
          
  routes
  .MapGet("api/get/{id}", (request, response, routeData) => {})
  .MapMiddlewareRoute("api/middleware", (appBuilder) => 
             appBuilder.Use((httpContext, next) => httpContext.Response.WriteAsync("Middleware!")
           ))
  .MapRoute(
     name: "AllVerbs",
     template: "api/all/{name}/{lastName?}",
     defaults: new { lastName = "Doe" },
     constraints: new { lastName = new RegexRouteConstraint(new Regex("[a-zA-Z]{3}",RegexOptions.CultureInvariant, RegexMatchTimeout)) });
});

按照上面的示例解釋一下，

MapRoute：使用這種方式的話，必須要給 DefaultHandler 賦值處理程序，否則會拋出異常，通常情況下我們會使用RouteHandler類。

MapVerb： MapPost,MapPut 等等都和它類似，它將處理程序作為一個(gè) RequestDelegate 委托提供了出來，也就是說我們實(shí)際上在自己處理HttpContext的東西，不會經(jīng)過RouteHandler處理。

MapMiddlewareRoute：需要傳入一個(gè) IApplicationBuilder 委托，實(shí)際上 IApplicationBuilder Build之后也是一個(gè) RequestDelegate，它會在內(nèi)部 new 一個(gè) RouteHandler 類，然后調(diào)用的 MapRoute。

這些所有的矛頭都指向了 RouteHandler ， 我們來看看 RouteHandler 吧。

public class RouteHandler : IRouteHandler, IRouter
{
  // ...略

  public Task RouteAsync(RouteContext context)
  {
    context.Handler = _requestDelegate;
    return TaskCache.CompletedTask;
  }
}

什么都沒干，僅僅是將傳入進(jìn)來的 RequestDelegate 賦值給了 RouteContext 的處理程序。

最后，代碼會執(zhí)行到 RouterMiddleware 類中的 Invoke 方法的最后一行 await context.Handler(context.HttpContext)，這個(gè)時(shí)候開始調(diào)用Handler委托，執(zhí)行用戶代碼。

總結(jié)

我們來總結(jié)一下以上流程：

首先傳入請求會到注冊的 RouterMiddleware 中間件，然后它 RouteAsync 按順序調(diào)用每個(gè)路由上的方法。當(dāng)一個(gè)請求到來的時(shí)候，IRouter實(shí)例選擇是否處理已經(jīng)設(shè)置到 RouteContext Handler 上的一個(gè)非空 RequestDelegate。如果Route已經(jīng)為該請求設(shè)置處理程序，則路由處理會中止并且開始調(diào)用設(shè)置的Hanlder處理程序以處理請求。如果當(dāng)前請求嘗試了所有路由都沒有找到處理程序的話，則調(diào)用next，將請求交給管道中的下一個(gè)中間件。

關(guān)于路由模板和參數(shù)約束源碼處理流程就不一一說了，有興趣可以直接看下源碼。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論