ASP.NET Core 中间件详解及项目实战

前言

在上篇文章主要介绍了DotNetCore项目状况，本篇文章是我们在开发自己的项目中实际使用的，比较贴合实际应用，算是对中间件的一个深入使用了，不是简单的Hello World，如果你觉得本篇文章对你有用的话，不妨点个【推荐】。

目录

  • 中间件（Middleware）的作用
  • 中间件的运行方式
  • 中间件（Middleware）和过滤器（Filter）的区别
  • 什么情况我们需要中间件
  • 怎么样自定义自己的中间件

中间件（Middleware）的作用

我们知道，任何的一个web框架都是把http请求封装成一个管道，每一次的请求都是经过管道的一系列操作，最终到达我们写的代码中。那么中间件就是在应用程序管道中的一个组件，用来拦截请求过程进行一些其他处理和响应。中间件可以有很多个，每一个中间件都可以对管道中的请求进行拦截，它可以决定是否将请求转移给下一个中间件。

asp.net core 提供了IApplicationBuilder接口来让把中间件注册到asp.net的管道请求当中去，中间件是一个典型的AOP应用。 下面是一个微软官方的一个中间件管道请求图：

可以看到，每一个中间件都都可以在请求之前和之后进行操作。请求处理完成之后传递给下一个请求。

中间件的运行方式

默认情况下，中间件的执行顺序根据Startup.cs文件中，在public void Configure(IApplicationBuilder app){} 方法中注册的先后顺序执行。
大概有3种方式可以在管道中注册"中间件"

  1. app.Use()，IApplicationBuilder接口原生提供，注册等都用它。
  2. app.Run() ，是一个扩展方法，它需要一个RequestDelegate委托，里面包含了Http的上下文信息，没有next参数，因为它总是在管道最后一步执行。
  3. app.Map()，也是一个扩展方法，类似于MVC的路由，用途一般是一些特殊请求路径的处理。如：www.example.com/token 等。

上面的Run，Map内部也是调用的Use，算是对IApplicationBuilder接口扩充，如果你觉得名字都不够准确，那么下面这个扩展方法就是正宗的注册中间件的了，也是功能最强大的。
app.UseMiddleware<>()，没错，就是这个了。 为什么说功能强大呢？是因为它不但提供了注册中间件的功能，还提供了依赖注入（DI）的功能，以后大部分情况就用它了。

中间件（Middleware）和过滤器（Filter）的区别

熟悉MVC框架的同学应该知道，MVC也提供了5大过滤器供我们用来处理请求前后需要执行的代码。分别是AuthenticationFilter,AuthorizationFilter,ActionFilter,ExceptionFilter,ResultFilter。

根据描述，可以看出中间件和过滤器的功能类似，那么他们有什么区别？为什么又要搞一个中间件呢？
其实，过滤器和中间件他们的关注点是不一样的，也就是说职责不一样，干的事情就不一样。

举个栗子，中间件像是埃辛诺斯战刃，过滤器像是巨龙之怒，泰蕾苟萨的寄魂杖 ,你一个战士拿着巨龙之怒，泰蕾苟萨的寄魂杖去战场杀人，虽然都有伤害，但是你拿着法杖伤害低不说，还减属性啊。

同作为两个AOP利器，过滤器更贴合业务，它关注于应用程序本身，比如你看ActionFilter 和 ResultFilter，它都直接和你的Action，ActionResult交互了，是不是离你很近的感觉，那我有一些比如对我的输出结果进行格式化啦，对我的请求的ViewModel进行数据验证啦，肯定就是用Filter无疑了。它是MVC的一部分，它可以拦截到你Action上下文的一些信息，而中间件是没有这个能力的。

什么情况我们需要中间件

那么，何时使用中间件呢？我的理解是在我们的应用程序当中和业务关系不大的一些需要在管道中做的事情可以使用，比如身份验证，Session存储，日志记录等。其实我们的 asp.net core项目中本身已经包含了很多个中间件。

举例，我们在新建一个 asp.net core应用程序的时候，默认生成的模板当中

public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    app.UseDeveloperExceptionPage();

    app.UseStaticFiles();

    loggerFactory.AddConsole();

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

懒得去下载源码了，我们使用Reflector去查看源码：

//扩展方法`app.UseDeveloperExceptionPage();`
public static class DeveloperExceptionPageExtensions
{
    // Methods
    public static IApplicationBuilder UseDeveloperExceptionPage(this IApplicationBuilder app)
    {
        if (app == null)
        {
            throw new ArgumentNullException("app");
        }
        return UseMiddlewareExtensions.UseMiddleware<DeveloperExceptionPageMiddleware>(app, Array.Empty<object>());
    }
}


//扩展方法`app.UseStaticFiles();`
public static class StaticFileExtensions
{
   // Methods
   public static IApplicationBuilder UseStaticFiles(this IApplicationBuilder app)
    {
        if (app == null)
        {
            throw new ArgumentNullException("app");
        }
        return UseMiddlewareExtensions.UseMiddleware<StaticFileMiddleware>(app, Array.Empty<object>());
    }
}

可以看到 app.UseDeveloperExceptionPage()，app.UseStaticFiles()等等都是通过中间件实现的。

怎么样自定义自己的中间件

背景：我们项目使用到中间件的情景是，需要和其他部门进行用户(User)信息的共享。 以平台和子系统举例，我们正在开发一个子系统，其中用户信息，登录，注册等功能是放在平台上的，这是一个跨多语言的系统，平台是Java语言开发，用户在访问子系统的一些页面的时候需要验证是否登录，另外一些页面是不需要验证是否登录的，所以需要一个身份验证系统来代替Identity的功能。

幸运的是微软已经给我们提供了一套身份验证的中间件，在Microsoft.AspNetCore.Authentication命名空间下，我们只需要拓展，添加自己的功能就行了 。具体怎么做呢？直接看代码吧。

根据约定俗成，中间件类需要有一个Invoke方法，签名是public async Task Invoke(HttpContext context){}，下面是一个中间件的示例类：

public class RequestLoggerMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger _logger;

    public RequestLoggerMiddleware(RequestDelegate next, ILoggerFactory loggerFactory)
    {
        _next = next;
        _logger = loggerFactory.CreateLogger<RequestLoggerMiddleware>();
    }

    public async Task Invoke(HttpContext context)
    {
        _logger.LogInformation("Handling request: " + context.Request.Path);
        await _next.Invoke(context);
        _logger.LogInformation("Finished handling request.");
    }
}

了解了上面的约定之后，我们就开始定义我们自己的中间件Class。

我们需要一个流程图来理清逻辑思路，以便于写代码的时候思路更加的清晰。

平台有一个要求就是，用户在我们子系统退出之后，要调用平台的一个接口通知他们，他们要做一些后续的业务。

OK，开始撸码。

  • 首先创建一个PlatformAuthoricationMiddleware，它继承于Microsoft.AspNetCore.Authentication下的类AuthenticationMiddleware，由于AuthenticationMiddleware已经实现了Invoke功能，所以我们只需要重写(override)它里面的一些方法就可以了。等等，我们好像还需要一些配置，比如流程图中的ReturnUrl，平台的Cookie的Key值，平台验证用户合法性的接口地址等参数。
  • 建立一个Options类进行配置的设置，我们取名字为：PlatformAuthenticationOptions，继承AuthenticationOptions，并且实现掉IOptions<T>接口，这样子就能在Startup中直接配置了。
  • 我们只需要重写AuthenticationMiddleware中的CreateHandler方法就行了，在Handler中可以实现掉我们中间件的功能。
  • 然后创建一个处理的Handler类，取名为PlatformAuthenticationHandler，继承于AuthenticationHandler<TOptions>用来处理请求中的调用。

至此，我们的核心需要的类已经建立完了，剩下的就是填充代码。

  1. 在PlatformAuthenticationHandler中重写HandleAuthenticateAsync()方法 ， 进行主流程的控制。
  2. 在PlatformAuthenticationHandler中重写FinishResponseAsync()方法，进行Session的存储操作。
  3. 在PlatformAuthenticationHandler中重写HandleSignOutAsync()方法，进行登出的控制，因为用户登出之后我们要通知平台做一些其他操作。
  4. 在PlatformAuthenticationHandler中重写HandleUnauthorizedAsync()方法，进行未认证操作。

最后，我们需要一个扩展类来把我们的中间件以扩展方法注册到管道当中去 。

public static class MiddlewareExtensions
{
    public static IApplicationBuilder UsePlatformAuthentication(this IApplicationBuilder app) {
        if (app == null) {
            throw new ArgumentNullException(nameof(app));
        }

        return app.UseMiddleware<PlatformAuthenticationMiddleware>();
    }

    public static IApplicationBuilder UsePlatformAuthentication(this IApplicationBuilder app, CookieAuthenticationOptions options) {
        if (app == null) {
            throw new ArgumentNullException(nameof(app));
        }
        if (options == null) {
            throw new ArgumentNullException(nameof(options));
        }

        return app.UseMiddleware<PlatformAuthenticationMiddleware>(Options.Create(options));
    }
}

在Startup中就是app.UsePlatformAuthentication()

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) {
    loggerFactory.AddConsole(Configuration.GetSection("Logging"));

    //注册PlatformAuthentication中间件
    app.UsePlatformAuthentication(new PlatformAuthenticationOptions() {
        UserSessionStore = new UserSessionStore(),
    });

    app.UseMvc();
}

现在，我们的中间件核心业务流程的实现已经出来了，我就不大篇幅的粘贴代码了，会影响阅读，感兴趣具体实现的朋友可以去下面的地址查看代码，有具体流程的注释。

示例源码：
https://github.com/yuleyule66/PlatformAuthMiddleware

原文：http://www.cnblogs.com/savorboard/p/5586229.html

时间： 2024-08-08 13:53:18

ASP.NET Core 中间件详解及项目实战的相关文章

net core 中间件详解及项目实战

net core 中间件详解及项目实战 前言 在上篇文章主要介绍了DotNetCore项目状况,本篇文章是我们在开发自己的项目中实际使用的,比较贴合实际应用,算是对中间件的一个深入使用了,不是简单的Hello World,如果你觉得本篇文章对你有用的话,不妨点个[推荐]. 目录 中间件(Middleware)的作用 中间件的运行方式 中间件(Middleware)和过滤器(Filter)的区别 什么情况我们需要中间件 怎么样自定义自己的中间件 中间件(Middleware)的作用 我们知道,任何

asp.net core 中间件粗解

中间件 中间件在asp.net core中非常重要,它用来处理httpcontext.而httpcontext封装了请求和响应.也就是说,中间件是用来处理请求和响应的. 本质上,中间件被封装到了IApplicationBuilder这个接口中,他的实现类是ApplicationBuilder.源码在github:https://github.com/aspnet/HttpAbstractions ApplicationBuilder有两个方法和一个字段比较重要: private readonly

ASP.NETCore学习记录(二) —— ASP.NET Core 中间件

ASP.NET Core 中间件 目录: IApplicationBuilder 什么是中间件 ? 使用 IApplicationBuilder 创建中间件 Run.Map 与 Use 方法 实战中间件 参考原文 我们知道在 ASP.NET 中,有一个面向切面的请求管道,由22个主要的事件构成,能够让我们在往预定的执行顺序里面添加自己的处理逻辑.一般采取两种方式:一种是直接在 Global.asax 中对应的方法中直接添加代码.一种是是在 web.config 中通过注册 HttpModule

Asp.net core 中间件简单应用

Asp.net core中间件 ,处理http请求和响应的中间组件,对比起asp.net ,asp.net core 管道机制,可以说是帅气十足,简单直接.下面是通过中间件对一个请求的url 指定路由 新建webapi 项目 Startup类中Configure方法中添加处理中间件代码如下 public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app

ASP.NET Core中间件(Middleware)实现WCF SOAP服务端解析

ASP.NET Core中间件(Middleware)进阶学习实现SOAP 解析. 本篇将介绍实现ASP.NET Core SOAP服务端解析,而不是ASP.NET Core整个WCF host. 因为WCF中不仅仅只是有SOAP, 它还包含很多如消息安全性,生成WSDL,双工信道,非HTTP传输等. ASP.NET Core 官方推荐大家使用RESTful Web API的解决方案提供网络服务. SOAP 即 Simple Object AccessProtocol 也就是简单对象访问协议.

ASP.NET生命周期详解 [转]

最近一直在学习ASP.NET MVC的生命周期,发现ASP.NET MVC是建立在ASP.NET Framework基础之上的,所以原来对于ASP.NET WebForm中的很多处理流程,如管道事件等,对于ASP.NET MVC同样适用.只是MVC URLRouting Module对进入到server的request进行了拦截,然后对此次request的handler进行了特殊的处理.总结来说,就是 ASP.NET管道是所有ASP.NET Web Applicaiton,包括WebForm,

ASP.NET运行时详解 中篇

遗留问题 在ASP.NET运行时详解 上篇中遗留两个问题,包括Application的InitInternal方法执行细节.IIS6和II7经典模式请求管道管理类ApplicationStepManager和IIS7请求管道管理类PipelineStepManager的实现细节.这两个问题贯穿了整个ASP.NET运行过程.所以,要把ASP.NET运行过程了解清楚,这两个问题不得不解决.    为了大家更容易切入该篇的内容,我们先回顾下这两个问题: 1. Application的InitInter

ASP.NET Global.asax详解

http://blog.csdn.net/xiarenwang/article/details/7633160 文档来源:http://club.topsage.com/thread-485397-1-1.html global.asax是一个文本文件,它提供全局可用代码.这些代码包括应用程序的事件处理程序以及会话事件.方法和静态变量.有时该文件也被称为应用程序文件. global.asax 文件中的任何代码都是它所在的应用程序的一部分.每个应用程序在其根目录下只能有一个global.asax文

ASP.NET 运行时详解 揭开请求过程神秘面纱

对于ASP.NET开发,排在前五的话题离不开请求生命周期.像什么Cache.身份认证.Role管理.Routing映射,微软到底在请求过程中干了哪些隐秘的事,现在是时候揭晓了.抛开乌云见晴天,接下来就一步步揭开请求管道神秘面纱. 上篇回顾 在介绍本篇内容之前,让我们先回顾下上一篇<ASP.NET运行时详解 集成模式和经典模式>的主要内容.在上一篇随笔中,我们提到ASP.NET运行时通过Application的InitInternal方法初始化运行管道.ASP.NET运行时提供了两种初始化管道模