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

前言

本篇文章是我们在开发自己的项目中实际使用的，比较贴合实际应用，算是对中间件的一个深入使用了，不是简单的hello world。

中间件（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的路由，用途一般是一些特殊请求路径的处理。如： 等。

上面的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();
}

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

示例源码：demo

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。