.NET Core开发日志——RequestDelegate

本文主要是对.NET Core开发日志——Middleware的补遗,但是会从看起来平平无奇的RequestDelegate开始叙述,所以以其作为标题,也是合情合理。

RequestDelegate是一种委托类型,其全貌为public delegate Task RequestDelegate(HttpContext context),MSDN上对它的解释,"A function that can process an HTTP request."——处理HTTP请求的函数。唯一参数,是最熟悉不过的HttpContext,返回值则是表示请求处理完成的异步操作类型。

可以将其理解为ASP.NET Core中对一切HTTP请求处理的抽象(委托类型本身可视为函数模板,其实现具有统一的参数列表及返回值类型),没有它整个框架就失去了对HTTP请求的处理能力。

并且它也是构成Middleware的基石。或者更准确地说参数与返回值都是其的Func<RequestDelegate, RequestDelegate>委托类型正是维持Middleware运转的核心齿轮。

组装齿轮的地方位于ApplicationBuilder类之内,其中包含着所有齿轮的集合。

private readonly IList<Func<RequestDelegate, RequestDelegate>> _components = new List<Func<RequestDelegate, RequestDelegate>>();

以及添加齿轮的方法:

public IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware)
{
    _components.Add(middleware);
    return this;
}

在Startup类的Configure方法里调用以上ApplicationBuilder的Use方法,就可以完成一个最简单的Middleware。

public void Configure(IApplicationBuilder app)
{
    app.Use(_ =>
    {
        return context =>
        {
            return context.Response.WriteAsync("Hello, World!");
        };

    });
}

齿轮要想变成Middleware,在完成添加后,还需要经过组装。

public RequestDelegate Build()
{
    RequestDelegate app = context =>
    {
        context.Response.StatusCode = 404;
        return Task.CompletedTask;
    };

    foreach (var component in _components.Reverse())
    {
        app = component(app);
    }

    return app;
}

Build方法里先定义了最底层的零件——app,context => { context.Response.StatusCode = 404; return Task.CompletedTask; },这段代码意味着,如果没有添加任何Middleware的话,ASP.NET Core站点启动后,会直接出现404的错误。

接下的一段,遍历倒序排列的齿轮,开始正式组装。

在上述例子里,只使用了一个齿轮:

_ =>
{
    return context =>
    {
        return context.Response.WriteAsync("Hello, World!");
    };

}

那么第一次也是最后一次循环后,执行component(app)操作,app被重新赋值为:

context => context.Response.WriteAsync("Hello, World!");

组装的结果便是app的值。

这个组装过程在WebHost进行BuildApplication时开始操作。从此方法的返回值类型可以看出,虽然明义上是创建Application,其实生成的是RequestDelegate。

private RequestDelegate BuildApplication()
{
    try
    {
        ...

        var builderFactory = _applicationServices.GetRequiredService<IApplicationBuilderFactory>();
        var builder = builderFactory.CreateBuilder(Server.Features);
        ...
        Action<IApplicationBuilder> configure = _startup.Configure;
        ...

        configure(builder);

        return builder.Build();
    }
    ...
}    

而这个RequestDelegate最终会在HostingApplication类的ProcessRequestAsync方法里被调用。

public virtual async Task StartAsync(CancellationToken cancellationToken = default)
{
    ...

    var application = BuildApplication();

    ...
    var hostingApp = new HostingApplication(application, _logger, diagnosticSource, httpContextFactory);
    ...
}    

public HostingApplication(
    RequestDelegate application,
    ILogger logger,
    DiagnosticListener diagnosticSource,
    IHttpContextFactory httpContextFactory)
{
    _application = application;
    _diagnostics = new HostingApplicationDiagnostics(logger, diagnosticSource);
    _httpContextFactory = httpContextFactory;
}

public Task ProcessRequestAsync(Context context)
{
    return _application(context.HttpContext);
}

上例中的执行结果即是显示Hello, World!字符。

404的错误不再出现,意味着这种Middleware只会完成自己对HTTP请求的处理,并不会将请求传至下一层的Middleware。

要想达成不断传递请求的目的,需要使用另一种Use扩展方法。

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);
        };
    });
}

在实际代码中可以这么写:

public void Configure(IApplicationBuilder app)
{
    app.Use(async (context, next) =>
    {
        await context.Response.WriteAsync("I am a Middleware!\n");
        await next.Invoke();
    });

    app.Use(_ =>
    {
        return context =>
        {
            return context.Response.WriteAsync("Hello, World!");
        };
    });
}

现在多了个Middleware,继续上面的组装过程。app的值最终被赋值为:

async context =>
{
    Func<Task> simpleNext = () => context.Response.WriteAsync("Hello, World!"); 

    await context.Response.WriteAsync("I am a Middleware!\n");
    await simpleNext.Invoke();
};

显示结果为:

I am a Middleware!
Hello, World!

下面的流程图中可以清楚地说明这个过程。

如果把await next.Invoke()注释掉的话,

public void Configure(IApplicationBuilder app)
{
    app.Use(async (context, next) =>
    {
        await context.Response.WriteAsync("I am a Middleware!\n");
        //await next.Invoke();
    });

    app.Use(_ =>
    {
        return context =>
        {
            return context.Response.WriteAsync("Hello, World!");
        };

    });
}

上例中第一个Middleware处理完后,不会继续交给第二个Middleware处理。注意以下simpleNext的方法只被定义而没有被调用。

async context =>
{
    Func<Task> simpleNext = () => context.Response.WriteAsync("Hello, World!"); 

    await context.Response.WriteAsync("I am a Middleware!\n");
};

这种情况被称为短路(short-circuiting)。

做短路处理的Middleware一般会放在所有Middleware的最后,以作为整个pipeline的终点。

并且更常见的方式是用Run扩展方法。

public static void Run(this IApplicationBuilder app, RequestDelegate handler)
{
    ...

    app.Use(_ => handler);
}

所以可以把上面例子的代码改成下面的形式:

public void Configure(IApplicationBuilder app)
{
    app.Use(async (context, next) =>
    {
        await context.Response.WriteAsync("I am a Middleware!\n");
        await next.Invoke();
    });

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

除了短路之外,Middleware处理时还可以有分支的情况。

public void Configure(IApplicationBuilder app)
{
    app.Map("/branch1", ab => {
        ab.Run(async context =>
        {
            await context.Response.WriteAsync("Map branch 1");
        });
    });

    app.Map("/branch2", ab => {
        ab.Run(async context =>
        {
            await context.Response.WriteAsync("Map branch 2");
        });
    });

    app.Use(async (context, next) =>
    {
        await context.Response.WriteAsync("I am a Middleware!\n");
        await next.Invoke();
    });

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

URL地址后面跟着branch1时:

URL地址后面跟着branch2时:

其它情况下:

Map扩展方法的代码实现:

public static IApplicationBuilder Map(this IApplicationBuilder app, PathString pathMatch, Action<IApplicationBuilder> configuration)
{
    ...

    // create branch
    var branchBuilder = app.New();
    configuration(branchBuilder);
    var branch = branchBuilder.Build();

    var options = new MapOptions
    {
        Branch = branch,
        PathMatch = pathMatch,
    };
    return app.Use(next => new MapMiddleware(next, options).Invoke);
}

创建分支的办法就是重新实例化一个ApplicationBuilder。

public IApplicationBuilder New()
{
    return new ApplicationBuilder(this);
}

对分支的处理则是封装在MapMiddleware类之中。

public async Task Invoke(HttpContext context)
{
    ...

    PathString matchedPath;
    PathString remainingPath;

    if (context.Request.Path.StartsWithSegments(_options.PathMatch, out matchedPath, out remainingPath))
    {
        // Update the path
        var path = context.Request.Path;
        var pathBase = context.Request.PathBase;
        context.Request.PathBase = pathBase.Add(matchedPath);
        context.Request.Path = remainingPath;

        try
        {
            await _options.Branch(context);
        }
        finally
        {
            context.Request.PathBase = pathBase;
            context.Request.Path = path;
        }
    }
    else
    {
        await _next(context);
    }
}

说到MapMiddleware,不得不提及各种以Use开头的扩展方法,比如UseStaticFiles,UseMvc,UsePathBase等等。

这些方法内部都会调用UseMiddleware方法以使用各类定制的Middleware类。如下面UsePathBase的代码:

public static IApplicationBuilder UsePathBase(this IApplicationBuilder app, PathString pathBase)
{
    ...

    // Strip trailing slashes
    pathBase = pathBase.Value?.TrimEnd(‘/‘);
    if (!pathBase.HasValue)
    {
        return app;
    }

    return app.UseMiddleware<UsePathBaseMiddleware>(pathBase);
}

而从UseMiddleware方法中可以获知,Middleware类需满足两者条件之一才能被有效使用。其一是实现IMiddleware,其二,必须有Invoke或者InvokeAsync方法,且方法至少要有一个HttpContext类型参数(它还只能是放第一个),同时返回值需要是Task类型。

internal const string InvokeMethodName = "Invoke";
internal const string InvokeAsyncMethodName = "InvokeAsync";

public static IApplicationBuilder UseMiddleware(this IApplicationBuilder app, Type middleware, params object[] args)
{
    if (typeof(IMiddleware).GetTypeInfo().IsAssignableFrom(middleware.GetTypeInfo()))
    {
        ...

        return UseMiddlewareInterface(app, middleware);
    }

    var applicationServices = app.ApplicationServices;
    return app.Use(next =>
    {
        var methods = middleware.GetMethods(BindingFlags.Instance | BindingFlags.Public);
        var invokeMethods = methods.Where(m =>
            string.Equals(m.Name, InvokeMethodName, StringComparison.Ordinal)
            || string.Equals(m.Name, InvokeAsyncMethodName, StringComparison.Ordinal)
            ).ToArray();

        ...

        var ctorArgs = new object[args.Length + 1];
        ctorArgs[0] = next;
        Array.Copy(args, 0, ctorArgs, 1, args.Length);
        var instance = ActivatorUtilities.CreateInstance(app.ApplicationServices, middleware, ctorArgs);
        if (parameters.Length == 1)
        {
            return (RequestDelegate)methodinfo.CreateDelegate(typeof(RequestDelegate), instance);
        }

        var factory = Compile<object>(methodinfo, parameters);

        return context =>
        {
            var serviceProvider = context.RequestServices ?? applicationServices;
            ...
            return factory(instance, context, serviceProvider);
        };
    });
}

对ASP.NET Core中Middleware的介绍到此终于可以告一段落,希望这两篇文章能够为读者提供些许助力。

原文地址:https://www.cnblogs.com/kenwoo/p/9404671.html

时间: 2024-10-13 19:00:18

.NET Core开发日志——RequestDelegate的相关文章

.NET Core开发日志——Entity Framework与PostgreSQL

Entity Framework在.NET Core中被命名为Entity Framework Core.虽然一般会用于对SQL Server数据库进行数据操作,但其实它还支持其它数据库,这里就以PostgreSQL作为例子. PostgreSQL PostgreSQL可以选用原生系统与Docker两种安装方式. Official Docker Package 在应用程序工程中添加相关的引用. dotnet add package Npgsql.EntityFrameworkCore.Postg

.Net Core开发日志——从搭建开发环境开始

.Net Core自2016年推出1.0版本开始,到目前已是2.1版本,在其roadmap计划里明年更会推出3.0版本,发展不可不谓之迅捷.不少公司在经过一个谨慎的观望期后,也逐步开始将系统升级至最新的.Net Core平台,所以现在开始进行.Net Core开发可谓正当其时. 因为.Net Core支持Windows系统以外的Linux与Mac系统,在选择开发环境时,并不需要局限在原有的Windows平台,这里我选用了Mac平台. 开发硬件设备是一台14年款的Apple Macbook Air

.Net Core开发日志——Peachpie

.Net Core的生态圈随着开源社区的力量不断注入至其中,正在变得越来越强盛,并且不时得就出现些有意思的项目,比如Peachpie,它使得PHP的代码迁移到.Net Core项目变得可能. 从创建简单的入门程序开始可以更容易地体会其特性. 首先安装Peachpie的模板: dotnet new -i Peachpie.Templates::* 接着创建项目: dotnet new web -lang PHP -o helloPHP 然后切换目录至Server文件夹运行程序: cd Server

.NET Core开发日志——Startup

一个典型的ASP.NET Core应用程序会包含Program与Startup两个文件.Program类中有应用程序的入口方法Main,其中的处理逻辑通常是创建一个WebHostBuilder,再生成WebHost,最后启动之. 而在创建WebHostBuilder时又会常常会指定一个Startup类型. public static IWebHostBuilder CreateWebHostBuilder(string[] args) => WebHost.CreateDefaultBuilde

.NET Core开发日志——简述路由

有过ASP.NET或其它现代Web框架开发经历的开发者对路由这一名字应该不陌生.如果要用一句话解释什么是路由,可以这样形容:通过对URL的解析,指定相应的处理程序. 回忆下在Web Forms应用程序中使用路由的方式: public static void RegisterRoutes(RouteCollection routes) { routes.MapPageRoute("", "Category/{action}/{categoryName}", "

.NET Core开发日志——Model Binding

ASP.NET Core MVC中所提供的Model Binding功能简单但实用,其主要目的是将请求中包含的数据映射到action的方法参数中.这样就避免了开发者像在Web Forms时代那样需要从Request类中手动获取数据的繁锁操作,直接提高了开发效率.此功能继承自ASP.NET MVC,所以熟悉上一代框架开发的工程师,可以毫无障碍地继续享有它的便利. 本文想要探索下Model Binding相关的内容,这里先从源码中找到其发生的时机与场合. 在ControllerActionInvok

.NET Core开发日志——Linux版本的SQL Server

SQL Server 2017版本已经可以在Linux系统上安装,但我在尝试.NET Core跨平台开发的时候使用的是Mac系统,所以这里记录了在Mac上安装SQL Server的过程. 最新的SQL Server没有专门为Mac系统准备安装包,但由于Mac系统上支持Docker,所以可以用一种变通的方式--在Docker内部安装Linux版本的SQL Server. 系统要求 因为我的Macbook Air型号比较老,硬件条件很一般,所以首先确定下是否满足安装SQL Server的条件.官方给

.NET Core开发日志——结构化日志

在.NET生态圈中,最早被广泛使用的日志库可能是派生自Java世界里的Apache log4net.而其后来者,莫过于NLog.Nlog与log4net相比,有一项较显著的优势,它支持结构化日志. 结构化日志,也被称为语义化日志.其作用有二,利于查询与方便分析. 当系统上线被广泛使用或者时间久远之后,日志的大量出现不可避免.且日志本身作为一种数据,也有其重要的价值.因此,如何有效地对其进行查询以及最大价值化地分析处理便成了一个重要的问题. 非结构化日志 对于日志的处理,需要权衡对开发者的友好性与

.Net Core开发日志——Global Tools

.Net Core 2.1引入了一个新的功能,Global Tools,其本质是包含控制台应用程序的nuget包,目前而言,还没有特别有用的工具,不过相信随着时间的推移,各种有创意或者实用性强的Global Tools会出现在大家的视野里. 安装一个Global Tools很简单,输入一条命令dotnet tool install -g dotnetsay,名为dotnetsay的工具便已经安装在特定目录下. OS Path Linux/macOS $HOME/.dotnet/tools Win