.Net Core MVC理解新管道處理模型、中間件

.Net Core中間件官網：https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/middleware/?view=aspnetcore-3.0 ASP.Net請求管道：請求最終會由一個具體的HttpHandler處理（page/as ...

.Net Core中間件官網：https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/middleware/?view=aspnetcore-3.0

ASP.Net請求管道：

　　請求最終會由一個具體的HttpHandler處理（page/ashx/mvc httphandler---action）。但是還有多個步驟，被封裝成事件，可以註冊擴展，IHttpModule，提供了非常優秀的擴展。

　　但是這樣有一個缺陷，那就是太多管閑事了，一個http請求最核心的是IHttpHandler，其他的Cookie、Session、Session、BeginRequest、EndRequest、MapRequestHandler、授權等，不一定非得有這些請求的事件的邏輯，但是寫死了，就必須得有，預設認為那些步驟是必須有的，因為跟框架的設計思想有關。.Net Framework入門簡單精通難，因為框架大包大攬，全家桶式，WebForm裡面拖一個控制項然後就可以擼代碼了，一個項目就出來了，所以精通也難，也要付出代價，就是包袱比較重，不能輕裝前行。

ASP.Net Core：

ASP.NET Core 請求管道包含一系列請求委托，依次調用。下圖演示了這一概念。沿黑色箭頭執行。

　　ASP.NET Core是一套全新的平臺，已經不再向前相容，設計更追求組件化，追求高性能，沒有全家桶，那麼ASP.NET Core是怎麼搭建請求管道的呢？預設情況，管道只有一個404。然後你也可以增加請求的處理，這就是以前的Handler，只包含業務處理環節，其他的就是中間件，MiddleWare。

1、Run 終結式只是執行，沒有去調用Next ，一般作為終結點。所謂Run終結式註冊，其實只是一個擴展方法，最終還不是得調用Use方法，

app.Run(async (HttpContext context) =>
{
    await context.Response.WriteAsync("Hello World Run");
});
app.Run(async (HttpContext context) =>
{
    await context.Response.WriteAsync("Hello World Run Again");
});

2、Use表示註冊動作不是終結點，執行next，就可以執行下一個中間件如果不執行，就等於Run

app.Use(async (context, next) =>
{
    await context.Response.WriteAsync("Hello World Use1 <br/>");
    await next();
    await context.Response.WriteAsync("Hello World Use1 End <br/>");
});
app.Use(async (context, next) =>
{
    await context.Response.WriteAsync("Hello World Use2 Again <br/>");
    await next();
});

UseWhen可以對HttpContext檢測後，增加處理環節;原來的流程還是正常執行的

 app.UseWhen(context =>
 {
     return context.Request.Query.ContainsKey("Name");
 },
 appBuilder =>
 {
     appBuilder.Use(async (context, next) =>
     {
         await context.Response.WriteAsync("Hello World Use3 Again Again Again <br/>");
         await next();
     });
 });

app.Use（），沒有調用next（），那就是終結點，跟Run一樣

app.Use(async (context, next) =>
{
    await context.Response.WriteAsync("Hello World Use3  Again Again <br/>");
    //await next();
});

3、Map：根據條件指定中間件指向終結點，沒有Next，最好不要在中間件裡面判斷條件選擇分支；而是一個中間件只做一件事兒，多件事兒就多個中間件

app.Map("/Test", MapTest);
app.Map("/Bingle", a => a.Run(async context =>
{
    await context.Response.WriteAsync($"This is Bingle Site");
}));
app.MapWhen(context =>
{
    return context.Request.Query.ContainsKey("Name");
    //拒絕非chorme瀏覽器的請求  
    //多語言
    //把ajax統一處理
}, MapTest);

　　IApplicationBuilder 應用程式的組裝者，RequestDelegate:傳遞一個HttpContext，非同步操作下，不返回；也就是一個處理動作，Use(Func<RequestDelegate, RequestDelegate> middleware) 委托，傳入一個RequestDelegate，返回一個RequestDelegate。ApplicationBuilder裡面有個容器IList<Func<RequestDelegate, RequestDelegate>> _components，Use就只是去容器裡面添加個元素。最終會Build()一下，如果沒有任何註冊，就直接404處理一切，

 foreach (var component in _components.Reverse())//反轉集合  每個委托拿出來
{
    app = component.Invoke(app);
    //委托3-- 404作為參數調用，返回 委托3的內置動作--作為參數去調用委托(成為了委托2的參數)--迴圈下去---最終得到委托1的內置動作---請求來了HttpContext---
}

　　IApplicationBuilder build之後其實就是一個RequestDelegate，能對HttpContext加以處理，預設情況下，管道是空的，就是404；可以根據你的訴求，任意的配置執行，一切全部由開發者自由定製，框架只是提供了一個組裝方式

其實，中間件可以這樣寫。

Func<RequestDelegate, RequestDelegate> middleware = next =>
{
    return new RequestDelegate(async context =>
                    {
                        await context.Response.WriteAsync("<h3>This is Middleware1 start</h3>");
                        await Task.CompletedTask;
                        await next.Invoke(context);//RequestDelegate--需要context返回Task
                        await context.Response.WriteAsync("<h3>This is Middleware1 end</h3>");
                    });
};
app.Use(middleware);

每次都要這麼麻煩，去定義一個Func<RequestDelegate,RequestDelegate>，然後去使用嗎？我們可以進化一點點

 app.Use(next =>
 {
     System.Diagnostics.Debug.WriteLine("this is Middleware1");
     return new RequestDelegate(async context =>
     {
         await context.Response.WriteAsync("<h3>This is Middleware1 start</h3>");
         await next.Invoke(context);
         await context.Response.WriteAsync("<h3>This is Middleware1 end</h3>");
     });
 });

 app.Use(next =>
 {
     System.Diagnostics.Debug.WriteLine("this is Middleware2");
     return new RequestDelegate(async context =>
     {
         await context.Response.WriteAsync("<h3>This is Middleware2 start</h3>");
         await next.Invoke(context);
         await context.Response.WriteAsync("<h3>This is Middleware2 end</h3>");
     });
 });
 app.Use(next =>
 {
     System.Diagnostics.Debug.WriteLine("this is Middleware3");
     return new RequestDelegate(async context =>
     {
         await context.Response.WriteAsync("<h3>This is Middleware3 start</h3>");
         //await next.Invoke(context);//註釋掉，表示不再往下走
         await context.Response.WriteAsync("<h3>This is Middleware3 end</h3>");
     });
 });

執行的結果，順序為：

<h3>This is Middleware1 start</h3>
<h3>This is Middleware2 start</h3>
<h3>This is Middleware3 start</h3>

<h3>This is Middleware3 end</h3>
<h3>This is Middleware2 end</h3>
<h3>This is Middleware1 end</h3>

和以前ActionFilter是不是很像，是一個俄羅斯套娃，我比較喜歡說成洋蔥模型。其實是因為源碼中，將IList<Func<RequestDelegate,RequestDelegate>> _components，將_components.Reverse()使集合反轉了。

那中間件的代碼，下麵這種寫法不好嗎？

 app.Use(async (context, next) =>
 {
     //Do work that doesn't write to the Response
     await next.Invoke();
     //Do logging or other work that doesn't write to the Response
 });

 app.Run(async context =>
 {
     await context.Response.WriteAsync("Hello from 2nd delegate.");
 });

ApplicationBuilder裡面有個容器IList<Func<RequestDelegate,RequestDelegate>> _components。Use的時候就只是去容器裡面添加個元素，最終Build（）一下，如果沒有任何註冊，就直接404處理一切。

委托3---404作為參數調用，返回委托3的內置動作---作為參數去調用委托（成為了委托2的參數）---迴圈下去，最終得到委托1的內置動作，請求來了HttpContext，IApplicationBuilder，build之後其實就是一個RequestDelegate，能對HttpContext加以處理，預設情況下，管道是空的，就是404，可以根據你的訴求，任意的配置執行，一切全有開發者自由定製，框架只是提供了一個組裝方式。

中間件裡面的邏輯可以封裝到一個類中去：

 public class FirstMiddleWare
 {
     private readonly RequestDelegate _next;

     public FirstMiddleWare(RequestDelegate next)
     {
         this._next = next;
     }


     public async Task Invoke(HttpContext context)
     {
         await context.Response.WriteAsync($"{nameof(FirstMiddleWare)},Hello World1!<br/>");

         await _next(context);

         await context.Response.WriteAsync($"{nameof(FirstMiddleWare)},Hello World2!<br/>");
     }

 }

在使用的時候：

app.UseMiddleware<FirstMiddleWare>();

其實，我們可以再升級一點點，使用擴展方法，將這個類中的邏輯作為IApplicationBuilder的擴展方法。

public static class MiddleExtend
{
    public static IApplicationBuilder UseFirstMiddleWare(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<FirstMiddleWare>();
    }
}

在使用的時候就簡單多了

app.UseFirstMiddleWare();