探索ASP.NET Core中的IStartupFilter

原文：Exploring IStartupFilter in ASP.NET Core
作者：Andrew Lock
譯者：Lamond Lu

在本篇博客中，我將介紹一下IStartupFilter, 以及如何在ASP.NET Core中使用它。在下一篇博客中，我將介紹一下如何在外部中間件中使用IStartupFilter

IStartupFilter接口

IStartupFilter接口存在於Microsoft.AspNetCore.Hosting.Abstractions程序集中，它非常簡單，僅定義了一個接口方法。

namespace Microsoft.AspNetCore.Hosting
{
    public interface IStartupFilter
    {
        Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> next);
    }
}

其中Configure方法返回了一個變量Action 。

當創建一個ASP.NET Core應用程序的時候，IApplicationBuilder負責配置ASP.NET Core的中間件管道。例如你可以在Startup.cs文件的Configure方法中，看到以下類似的代碼。

public void Configure(IApplicationBuilder app)
{
    app.UseStaticFiles();

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

在這個方法中，你可以直接使用方法提供的IApplicationBuilder參數，並且可以向其中添加各種中間件。使用IStartupFilter, 你可以指定並返回一個Action 類型的泛型委托，這意味你除了可以使用方法提供的泛型委托配置IApplicationBuilder對象， 還需要返回一個泛型委托。

IStartupFilter方法可以接受一個配置IApplicationBuilder的方法，換而言之IStartupFilter.Configure方法可以使用Startup.Configure方法作為參數。

例：

Startup _startup = new Startup();
Action<IApplicationBuilder> startupConfigure = _startup.Configure;

//后續會補充StartupFilter1類的代碼
IStartupFilter filter1 = new StartupFilter1(); 

Action<IApplicationBuilder> filter1Configure = filter1.Configure(startupConfigure)

//后續會補充StartupFilter2類的代碼
IStartupFilter filter2 = new StartupFilter2(); 

Action<IApplicationBuilder> filter2Configure = filter2.Configure(filter1Configure)

如果之前你學習過ASP.NET Core的中間件管道，對於這個代碼，你可能會感覺很熟悉。這里我們正在建立另一條管道， 它是一個Configure方法的管道，而不是中間件管道。 這就是IStartupFilter的目的，允許在應用程序中創建Configure方法的管道。

實現IStartupFilter接口的對象何時會被調用?

現在我們對IStartupFilter的簽名有了更進一步的理解，接下來我們可以看看它在ASP.NET Core框架中的用法。

要查看IStartupFilter是如果被調用的，你可以在查看Microsoft.AspNetCore.Hosting程序集中的WebHost類。 當你在WebHostBuilder對象上調用Build方法時，實現IStartupFilter接口對象會被調用。 這個代碼通常出現在Program.cs文件中，例如：

public class Program
{
    public static void Main(string[] args)
    {
        var host = new WebHostBuilder()
            .UseKestrel()    
            .UseContentRoot(Directory.GetCurrentDirectory())
            .UseStartup<Startup>()
            .Build();  // 這個會調用BuildApplication方法

        host.Run(); 
    }
}

下面是BuildApplication方法的部分代碼，你可以看到這個方法負責初始化中間件管道。方法的返回值RequestDelegate表示了一個完整的管道，當請求到達的時候，Kestral服務器可以調用它。

private RequestDelegate BuildApplication()
{
    ..
    IApplicationBuilder builder = builderFactory.CreateBuilder(Server.Features);
    builder.ApplicationServices = _applicationServices;

    var startupFilters = _applicationServices.GetService<IEnumerable<IStartupFilter>>();
    Action<IApplicationBuilder> configure = _startup.Configure;
    foreach (var filter in startupFilters.Reverse())
    {
        configure = filter.Configure(configure);
    }

    configure(builder);

    return builder.Build();
}

首先，此方法創建IApplicationBuilder的實例，該實例將用於構建中間件管道，並將ApplicationServices設置為已配置的DI容器。

接下來的代碼塊很意思。首先，從DI容器中獲取了一個集合IEnumerable<IStartupFilter。正如我前面說的那樣，我們可以配置多個IStartupFilter來形成一個管道，所以這個方法只是從容器中取出它們。此外，Startup.Configure方法被保存到局部變量configure中, 這就是通常在Startup類中編寫的Configure方法，用於配置中間件管道。

現在我們通過循環遍歷每個IStartupFilter（以相反的順序），傳入Startup.Configure方法，然后更新局部變量configure來創建Configure方法的管道。這種方式實現了一種嵌套管道的效果。例如，如果我們有三個IStartupFilter實例，你最終會得到類似這樣的東西，其中內部Configure方法在參數中傳遞給外部方法：

局部變量configure的最終值會被IApplicationBuilder調用來執行實際的中間件管道配置。 調用builder.Build方法之后會生成處理HTTP請求所需的RequestDelegate。

一個IStartupFilter的例子

前面我雖然描述了IStartupFilter的用途，但是可能查看一些現成的實現會更容易理解一些。 默認情況下，WebHostBuilder在初始化時會注冊一個IStartupFilter - AutoRequestServicesStartupFilter

public class AutoRequestServicesStartupFilter : IStartupFilter
{
    public Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> next)
    {
        return builder =>
        {
            builder.UseMiddleware<RequestServicesContainerMiddleware>();
            next(builder);
        };
    }
}

本質上，它在中間件管道的開頭添加了一個額外的中間件，即RequestServicesContainerMiddleware。

這是唯一一個默認注冊的IStartupFilter，因此在這種情況下，參數next將是Startup類的Configure方法。

這基本上就是IStartupFilter的全部內容 - 它是一種在配置的管道的開頭或結尾添加額外中間件（或其他配置）的方法。

如何注冊IStartupFilter

注冊IStartupFilter很簡單，只需像往常一樣在你的ConfigureServices方法中注冊它。 默認情況下，在WebHostBuilder中已經注冊了AutoRequestServicesStartupFilter

private IServiceCollection BuildHostingServices()
{
    ...
    services.AddTransient<IStartupFilter, AutoRequestServicesStartupFilter>();
    ...
}

RequestServicesContainerMiddleware中間件

以下是RequestServicesContainerMiddleware的部分代碼

public class RequestServicesContainerMiddleware
{
    private readonly RequestDelegate _next;
    private IServiceScopeFactory _scopeFactory;

    public RequestServicesContainerMiddleware(RequestDelegate next, IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
        _next = next;
    }

    public async Task Invoke(HttpContext httpContext)
    {
        var existingFeature = httpContext.Features.Get<IServiceProvidersFeature>();

        if (existingFeature?.RequestServices != null)
        {
            await _next.Invoke(httpContext);
            return;
        }

        using (var feature = new RequestServicesFeature(_scopeFactory))
        {
            try
            {
                httpContext.Features.Set<IServiceProvidersFeature>(feature);
                await _next.Invoke(httpContext);
            }
            finally
            {
                httpContext.Features.Set(existingFeature);
            }
        }
    }
}

該中間件負責設置IServiceProvidersFeature。 創建時，RequestServicesFeature為請求創建新的IServiceScope和IServiceProvider。 它將負責使用Scoped生命周期添加到DI容器的依賴項的創建和處理。

IStartupFilter的使用場景

一般來說，我不認為在用戶的應用程序中需要使用IStartupFilter。 就其本質而言，用戶可以在Configure方法中定義中間件管道，因此IStartupFilter是不必要的。

我能想到以下幾種需要使用IStartupFilter的場景：

• 你自己創建了一個庫，你需要確保你的中間件在中間件管道的開頭（或結尾）運行。
• 你正在使用一個使用IStartupFilter的庫，您需要確保您的中間件在它之前運行。

總結

本篇博文中，我講解了IStartupFilter以及WebHost如何使用它在構建中間件管道。 在下一篇文章中，我將探討IStartupFilter的具體用法。

后記

本篇是作者早期的一篇博文，個人覺着對IStartupFilter講解的比較清楚，就翻譯了一下。在作者的后期博文中，作者提供了許多IStartupFilter的使用場景，例如

• 在ASP.NET Core項目啟動前，使用IStartupFilter驗證強類型配置
• 在ASP.NET Core項目啟動前，使用IStartupFilter進行數據庫遷移和緩存預讀取

有興趣的同學可以自己閱讀一下，后續我會選擇一些有意思的文章翻譯一下。