換個角度學習ASP.NET Core中間件
- 2020 年 5 月 23 日
- 筆記
- .NET Core, Asp.Net Core, 中間件
中間件真面目
關於ASP.NET Core中間件是啥，簡單一句話描述就是：用來處理HTTP請求和響應的一段邏輯，並且可以決定是否把請求傳遞到管道中的下一個中間件！
上面只是概念上的一種文字描述，那問題來了，中間件在程序中到底是個啥❓
一切還是從IApplicationBuilder說起，沒錯，就是大家熟悉的Startup類裏面那個Configure方法裏面的那個IApplicationBuilder（有點繞😵,抓住重點就行）。
IApplicationBuilder，應用構建者，聽這個名字就能感受它的核心地位，ASP.NET Core應用就是依賴它構建出來，看看它的定義：
public interface IApplicationBuilder
{
//...省略部分代碼...
IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);
RequestDelegate Build();
}
Use方法用來把中間件添加到應用管道中，此時我們已經看到中間件的真面目了，原來是一個委託，輸入參數是RequestDelegate，返回也是RequestDelegate，其實RequestDelegate還是個委託，如下：
public delegate Task RequestDelegate(HttpContext context);
還記得中間件是幹嘛的嗎？是用來處理http請求和響應的，即對HttpContext的處理，這裡我們可以看出來原來中間件的業務邏輯就是封裝在RequestDelegate裏面。
總結一下：
middleware就是Func<RequestDelegate, RequestDelegate>，輸入的是下一個中間件的業務處理邏輯，返回的就是當前中間件的業務處理邏輯，並在其中決定要不要調用下個中間件！我們代碼實現一個中間件看看（可能和我們平時用的不太一樣，但它就是中間件最原始的形式！）:
//Startup.Configure方法中
Func<RequestDelegate, RequestDelegate> middleware1 = next => async (context) =>
{
//處理http請求
Console.WriteLine("do something before invoke next middleware in middleware1");
//調用下一個中間件邏輯，當然根據業務實際情況，也可以不調用，那此時中間件管道調用到此就結束來了！
await next.Invoke(context);
Console.WriteLine("do something after invoke next middleware in middleware1");
};
//添加到應用中
app.Use(middleware1);
跑一下瞅瞅，成功執行中間件！
IIS Express is running.
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
Content root path: E:\vs2019Project\WebApplication3\WebApplication3
do something before invoke next middleware in middleware1
do something after invoke next middleware in middleware1
中間件管道
通過上面我們有沒有注意到，添加中間時，他們都是一個一個獨立的被添加進去，而中間件管道就是負責把中間件串聯起來，實現下面的一個中間件調用流轉流程：
如何實現呢？這個就是IApplicationBuilder中的Build的職責了，再次看下定義：
public interface IApplicationBuilder
{
//...省略部分代碼...
IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);
RequestDelegate Build();
}
Build方法一頓操作猛如虎，主要干一件事把中間件串聯起來，最後返回了一個 RequestDelegate，而這個就是我們添加的第一個中間件返回的RequestDelegate，
看下框架默認實現：
//ApplicationBuilder.cs
public RequestDelegate Build()
{
RequestDelegate app = context =>
{
// If we reach the end of the pipeline, but we have an endpoint, then something unexpected has happened.
// This could happen if user code sets an endpoint, but they forgot to add the UseEndpoint middleware.
var endpoint = context.GetEndpoint();
var endpointRequestDelegate = endpoint?.RequestDelegate;
if (endpointRequestDelegate != null)
{
var message =
$"The request reached the end of the pipeline without executing the endpoint: '{endpoint.DisplayName}'. " +
$"Please register the EndpointMiddleware using '{nameof(IApplicationBuilder)}.UseEndpoints(...)' if using " +
$"routing.";
throw new InvalidOperationException(message);
}
context.Response.StatusCode = 404;
return Task.CompletedTask;
};
foreach (var component in _components.Reverse())
{
app = component(app);
}
return app;
}
-
Build方法裏面定義了一個 RequestDelegate ，作為最後一個處理邏輯，例如返回404。
-
_components存儲着添加的所有中間件
-
中間件管道調度順序，就是按照中間添加的順序調用，所以中間件的順序很重要，很重要，很重要！
-
遍歷_components，傳入next RequestDelegate，獲取當前RequestDelegate，完成管道構建！
中間件使用
在此之前，還是提醒下，中間件最原始的使用姿勢就是
IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);
下面使用的方式，都是對此方式的擴展！
Lamda方式
大多數教程裏面都提到的方式，直接上代碼：
//擴展方法
//IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext, Func<Task>, Task> middleware)
app.Use(async (context, next) =>
{
Console.WriteLine("in m1");
await next.Invoke();
Console.WriteLine("out m1");
});
擴展方法簡化了中間件的使用，這個裏面就只負責寫核心邏輯，然後擴展方法中把它包裝成Func<RequestDelegate, RequestDelegate>類型進行添加，不像原始寫的那樣複雜，我們看下這個擴展方法實現，哈，原來就是一個簡單封裝！我們只要專註在middleware裏面寫核心業務邏輯即可。
public static IApplicationBuilder Use(this IApplicationBuilder app, Func<HttpContext, Func<Task>, Task> middleware)
{
return app.Use(next =>
{
return context =>
{
Func<Task> simpleNext = () => next(context);
return middleware(context, simpleNext);
};
});
}
如果我們定義中間件作為終端中間件(管道流轉此中間件就結束了，不再調用後面的中間件)使用時，上面只要不調用next即可。
當然我們還有另外一個選擇，自己使用擴展Run方法，傳入的參數就是RequestDelegate，還是上代碼：
//擴展方法
//public static void Run(this IApplicationBuilder app, RequestDelegate handler);
app.Run(async (context) =>
{
Console.WriteLine("in m3");
await context.Response.WriteAsync("test22");
Console.WriteLine("out m3");
});
到此，我們有沒有發現上面的方式有些弊端，只能處理下簡單邏輯，如果要依賴第三方服務，那可怎麼辦？
定義中間件類方式
使用中間件類，我們只要按照約定的方式，即類中包含InvokeAsync方法，就可以了。
使用類後，我們就可以注入我們需要的第三方服務，然後完成更複雜的業務邏輯，上代碼
//定義第三方服務
public interface ITestService
{
Task Test(HttpContext context);
}
public class TestService : ITestService
{
private int _times = 0;
public Task Test(HttpContext context)
{
return context.Response.WriteAsync($"{nameof(TestService)}.{nameof(TestService.Test)} is called {++_times} times\n");
}
}
//添加到IOC容器
public void ConfigureServices(IServiceCollection services)
{
services.AddTransient<ITestService, TestService>();
}
//中間件類，注入ITestService
public class CustomeMiddleware1
{
private int _cnt;
private RequestDelegate _next;
private ITestService _testService;
public CustomeMiddleware1(RequestDelegate next, ITestService testService)
{
_next = next;
_cnt = 0;
_testService = testService;
}
public async Task InvokeAsync(HttpContext context)
{
await _testService?.Test(context);
await context.Response.WriteAsync($"{nameof(CustomeMiddleware1)} invoked {++_cnt} times");
}
}
//添加中間件，還是一個擴展方法，預知詳情，請看源碼
app.UseMiddleware<CustomeMiddleware1>();
運行一下，跑出來的結果如下，完美！
等一下，有沒有發現上面有啥問題？？？❓
明明ITestService是以Transient註冊到容器裏面，應該每次使用都是新實例化的，那不應該被顯示被調用 15 次啊！！！
這個時候我們應該發現，我們上面的所有方式添加的中間件的生命周期其實和應用程序是一致的，也就是說是只在程序啟動的時候實例化一次！所以這裡第三方的服務，然後以Transient方式註冊到容器，但在中間件裏面變現出來就是一個單例效果，這就為什麼我們不建議在中間件裏面注入DbContext了，因為DbContext我們一般是以Scoped來用的，一次http請求結束，我們就要釋放它！
如果我們就是要在中間件裏面是有ITestService，而且還是Transient的效果，怎麼辦？
實現IMiddleware接口
//接口定義
public interface IMiddleware
{
ask InvokeAsync(HttpContext context, RequestDelegate next);
}
//實現接口
public class CustomeMiddleware : IMiddleware
{
private int _cnt;
private ITestService _testService;
public CustomeMiddleware(ITestService testService)
{
_cnt = 0;
_testService = testService;
}
public async Task InvokeAsync(HttpContext context, RequestDelegate next)
{
await _testService?.Test(context);
await context.Response.WriteAsync($"{nameof(CustomeMiddleware)} invoked {++_cnt} times");
}
}
//添加中間件
app.UseMiddleware<CustomeMiddleware>();
運行一下，結果報錯了… ，提示CustomeMiddleware沒有註冊！
InvalidOperationException: No service for type 'WebApplication3.CustomeMiddleware' has been registered.
通過報錯信息，我們已經知道，如果實現了IMiddleware接口的中間件，他們並不是在應用啟動時就實例化好的，而是每次都是從IOC容器中獲取的，其中就是IMiddlewareFactory
來解析出對應類型的中間件的（內部就是調用IServiceProvider），了解到此，我們就知道，此類中間件此時是需要以service的方式註冊到IOC容器裏面的，這樣中間件就可以根據註冊時候指定的生命周期方式來實例化，從而解決了我們上一節提出的疑問了！好了，我們註冊下中間件服務
public void ConfigureServices(IServiceCollection services)
{
services.AddTransient<CustomeMiddleware>();
services.AddTransient<ITestService, TestService>();
}
再次多次刷新請求，返回都是下面的內容
TestService.Test is called 1 times
CustomeMiddleware invoked 1 times
結語
中間件存在這麼多的使用方式，每一個存在都是為了解決實際需求的，當我們了解這些背景知識後，在後面自己使用時，就能更加的靈活！
