ASP.NET Core 從2.2版本開始，採用了一個新的名為Endpoint的路由方案，與原來的方案在使用上差別不大，但從內部執行方式上來說，差別還是很大的。上一篇ASP.NET Core;圖解路由(2.1 earler)詳細介紹了原版路由方案的執行機制，本文仍然透過一幅圖來瞭解一下新版的執行機制，最後再總結一下二者的異同點。

一、概述

       此方案從2.2版本開始，被稱作終結點路由（下文以“新版”稱呼），它是預設開啟的，若想採用原來的方案（<=2.1,下文以原版稱呼），可以在AddMvc的時候進行設定

services.AddMvc(option=>option.EnableEndpointRouting = false).SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

EnableEndpointRouting 預設為true，也就是啟用新的Endpoint方案，設定為false則採用舊版（<=2.1）的路由方案。

        在配置方法上來說，系統仍然採用在Startup中的use.Mvc()中配置，而實際上內部的處理中介軟體已由原來的RouterMiddleware改為EndpointMiddleware和EndpointRoutingMiddleware兩個中介軟體處理，下麵依舊透過一幅圖來詳細看一下：

 二、流程及解析

                                                                            圖一

為了方便檢視，依然對幾個“重點物件”做了顏色標識（點選圖片可以看大圖）：

      1. 路由的初始化配置（圖的前兩個泳道） 

1. ①  一切依然是從Startup開始，而且和舊版一樣，是透過UseMvc方法進行配置，傳入routes.MapRoute(…)這樣的一個或多個配置, 不做贅述。

1. 下麵著重說一下後面的流程，看一下MvcApplicationBuilderExtensions中的UseMvc方法：

② 第6行，這裡會獲取並判斷設定的EnableEndpointRouting的值，若為false，則採用舊版路由，詳見上一篇文章；該值預設為true，即採用新版路由。
③ 對應第9行，MvcEndpointDataSource在新版路由中是個非常非常重要的角色，在啟動初始化階段，它完成了路由表儲存和轉換，此處先用顏色重點標記一下，大家記住它，在後面的流程中詳細介紹。
④ 對應第16行，同舊版的RouteBuilder一樣，這裡會new一個 endpointRouteBuilder，二者都是一個IRouteBuilder，所以也同樣呼叫configureRoutes(endpointRouteBuilder)方法（也就是startup中的配置）獲取了一個Route的集合（IList）賦值給endpointRouteBuilder.Routes，這裡有個特別該註意的地方if (router is Route route && router.GetType() == typeof(Route)) ，也就是這裡只接受route型別，終結點路由系統不支援基於 IRouter的可擴充套件性，包括從 Route繼承。
⑤ 對應第20行，這裡對剛獲取到的endpointRouteBuilder.Routes進行遍歷，轉換成了一個MvcEndpointInfo的集和，賦值給mvcEndpointDataSource.ConventionalEndpointInfos。
⑥ 之後就是向管道塞中介軟體了，這裡的處理中介軟體由原來的RouterMiddleware改為EndpointMiddleware和EndpointRoutingMiddleware。

  2.請求的處理（圖的後兩個泳道）

       請求的處理大部分功能在中介軟體EndpointRoutingMiddleware，他有個重要的屬性_endpointDataSource儲存了上文中初始化階段生成的MvcEndpointDataSource，而中介軟體EndpointMiddleware的功能比較簡單，主要是在EndpointRoutingMiddleware篩選出endpoint之後，呼叫該endpoint的endpoint.RequestDelegate(httpContext)進行請求處理。
⑦ InitializeAsync()方法主要是用於呼叫InitializeCoreAsync()建立一個matcher，而透過這個方法的程式碼可以看出它只是在第一次請求的時候執行一次。

   ⑧ MvcEndpointDataSource一個重要的方法UpdateEndpoints()，作用是讀取所有action，並將這個action串列與它的ConventionalEndpointInfos串列（見⑤）進行匹配，最終生成一個新的串列。如下圖，我們預設情況下只配置了一個”{controller=Home}/{action=Index}/{id?}”這樣的路由，預設的HomeController有三個action，添加了一個名為FlyLoloController的controller並添加了一個帶屬性路由的action，最終生成了7個Endpoint，這有點像路由與action的“乘積”。當然，這裡只是用預設程式舉了個簡單的例子，實際專案中可能會有更多的路由模板註冊、會有更多的Controller和Action以及屬性路由等。

                                                      圖二

具體程式碼如下：

本質就是計算出一個個可能被請求的請求終結點，也就是Endpoint。由此可見，如上一篇文章那樣想自定義一個handler來處理特殊模板的方式（如 routes.MapRoute(“flylolo/{code}/{name}”, MyRouteHandler.Handler);）將被忽略掉，因其無法生成 Endpoint，且此種方式完全可以自定義一個中介軟體來實現，沒必要混在路由中。

            ⑨ 就是用上面生成的Matcher，攜帶Endpoint串列與請求URL做匹配，並將匹配到的Endpoint賦值給feature.Endpoint。
⑩ 獲取feature.Endpoint，若存在則呼叫其RequestDelegate處理請求httpContext。

 三、新版與舊版的異同點總結

簡要從應用系統啟動和請求處理兩個階段對比說一下兩個版本的區別：

1.啟動階段：

這個階段大部分都差不多，都是透過Startup的app.UseMvc()方法配置一個路由表，一個Route的集合Routes（IList），然後將其簡單轉換一下

<=2.1:  將Routes轉換為RouteCollection

2.2+ :   將Routes轉換為List

二者區別不大，雖然名字不同，但本質上還是差不多，都仍可理解為Route的集合的包裝。

2.請求處理階段：

<=2.1:   1. 將請求的URL與RouteCollection中記錄的路由模板進行匹配。

           2. 找到匹配的Route之後，再根據這個請求的URL判斷是否存在對應的Controlled和Action。

           3. 若以上均透過，則呼叫Route的Handler對HttpContext進行處理。

2.2+ :   1. 第一次處理請求時，首先根據啟動階段所配置的路由集合List和_actions.ActionDescriptors.Items（所有的action的資訊）做匹配，生成一個串列，這個串列儲存了所有可能被匹配的URL模板，如圖二，這個串列同樣是List，記錄了所有可能的URL樣式，實際上是列出了一個個可以被訪問的詳細地址，已經算是最終地址了，即終結點，或許就是為什麼叫Endpoint路由的原因。

            2.請求的Url和這個生成的表做匹配，找到對應的MvcEndpointInfo。

            3. 呼叫被匹配的MvcEndpointInfo的RequestDelegate方法對請求進行處理。

二者區別就是對於_actions.ActionDescriptors.Items（所有的action的資訊）的匹配上，原版是先根據路由模板匹配後，再根據ActionDescriptors判斷是否存在對應的Controller和action，而新版是先利用了action資訊與路由模板匹配，然後再用請求的URL進行匹配，由於這樣的工作只在第一次請求的時候執行，所以雖然沒有做執行效率上的測試，但感覺應該是比之前快的。 

原文連結：https://www.cnblogs.com/FlyLolo/p/ASPNETCore2_16.html