ASP.NET Core的中间件与管道介绍
今天来讨论一个asp.net core 很重要概念管道和中间件,在asp.net core中,针对http请求采用pipeline也就是通常说的管道方式来处理,而管道容器内可以挂载很多中间件(处理逻辑)“串联”来处理http请求,每一个中间件都有权决定是否需要执行下一个中间件,或者直接做出响应。这样的机制使得http请求能够很好的被层层处理和控制,并且层次清晰处理起来甚是方便。 示意图如下:
为了再次说明管道和中间件的概念,举一个官方给出的权限验证的例子,中间件a,b分别按顺序挂载在管道容器中,a为权限验证中间件,只有通过a的权限验证才能执行b,如果没有通过a的验证,a有权中断管道处理直接返回相应的错误提示例如401等。这样必须由上一节点来调用的串行递归执行方式就是pipeline,而每一个节点就是中间件或者叫中间组件。现在我们来看看如何在asp.net core中使用中间件和管理自己的http管道
环境配置与startup
在了解中间件之前我们需要先知道startup这个类具体运作方式,我们以下面这段代码为例:
/// <summary> /// web宿主的入口类 /// </summary> public class startup { //加入服务项到容器, 这个方法将会被runtime调用 public void configureservices(iservicecollection services) { } /// <summary> /// 配置http请求管道 /// </summary> /// <param name="app">被用于构建应用程序的请求管道 只可以在startup中的configure方法里使用</param> /// <param name="env">提供了访问应用程序属性,如环境变量</param> /// <param name="loggerfactory">提供了创建日志的机制</param> public void configure(iapplicationbuilder app,ihostingenvironment env,iloggerfactory loggerfactory) { loggerfactory.addconsole(); if (env.isdevelopment()) //根据配置的环境为开发环境,则会配置抛出异常错误界面 { app.usedeveloperexceptionpage(); //抛出详细的异常错误界面 } //管道断路 app.run(async (context) => { await context.response.writeasync("hello world!"); }); } }
可以看到 startup.cs 内有两个方法,一个是用来配置接口服务到管道容器中的configureservices, 一个是用来配置管道中间件的configure。
为什么必须是这两个方法名?
其实这两个方法名并不是规定死的,但也不是任意规定的,他是根据容器的环境变量来判断的,这里先给出官方文档《多环境下工作》。
我们可以在文档中了解到,core使用“aspnetcore_environment”字段来描述当前运行环境名称这就是上文中提到的环境配置,官方预设了3个环境名分别是development(开发环境), staging(测试环境), production(生产环境),如果您使用的是vscode您可以在.vscode文件夹下的launch.json中找到“aspnetcore_environment”字段,可以发现默认情况下是development,那说这些到底有什么用呢?
在startup中规定,配置服务和中间件两个方法可以根据环境名称来命名和选择调用,命名规则为configureservices{environment}和configure{environment}。如aspnetcore_environment = “development” 则configureservices和configure 可以写成configureservicesdevelopment 和configuredevelopment ,其他也是如此。这样就可以通过配置aspnetcore_environment 来决定该调用哪一个配置方法了。
configureservices和configure是什么环境下的呢?
configureservices和configure就好像switch 语句中的 default一样的道理,如果没有找到任何符合环境名的方法名,就会执行调用这两个方法。如配置了development,但却没有给出configureservicesdevelopment ,这时就会执行configureservices,如果都没有就会抛出异常。
必须设置成预设环境名吗?
环境名配置的参数名不必是预设值,你可以自己写一个,比如logenv等等。
接下来我们看一下实现的代码:
/// <summary> /// web宿主的入口类 /// </summary> public class startup { //加入服务项到容器, 这个方法将会被runtime调用 public void configureservices(iservicecollection services) { } /// <summary> /// log环境下配置http请求管道 /// </summary> /// <param name="app"></param> public void configureloghelp(iapplicationbuilder app){ app.run(async (context) => { await context.response.writeasync("hello world - configureloghelp"); }); } /// <summary> /// 开发环境下配置http请求管道 /// </summary> /// <param name="app"></param> public void configuredevelopment(iapplicationbuilder app){ app.run(async (context) => { await context.response.writeasync("hello world - configuredevelopment"); }); } /// <summary> /// 默认情况下配置http请求管道 /// </summary> /// <param name="app">被用于构建应用程序的请求管道。只可以在 startup 中的 configure 方法里使用</param> /// <param name="env">提供了访问应用程序属性,如环境变量</param> /// <param name="loggerfactory">提供了创建日志的机制</param> public void configure(iapplicationbuilder app, ihostingenvironment env, iloggerfactory loggerfactory) { //管道断路 app.run(async (context) => { await context.response.writeasync("hello world!"); }); }
当aspnetcore_environment = “development”
当aspnetcore_environment = “loghelp”
这样做的好处就是你可以写自己的测试配置而不会影响到其他人或者开发过程。当然环境的作用还在于前端应该引用什么样的css和js,关于这些我们之后在mvc的章节再来讨论, 想了解的博友可以看官方文档
管道配置与startup
说完环境配置和startup的关系,我们回来接着聊管道的事情,现在我们来说说configure{environment}一下configure简称这个方法。
configure这个方法是用于配置中间件到中管道容器(iapplicationbuilder),所以这个方法必须要包含一个iapplicationbuilder参数用来接受管道容器,方便开发者配置。当然他还可以接受其他的可选参数供开发者使用如下:
(注:下图来源于asp.net core中文文档)
需要提一下的是,刚刚我们上文中说的环境名在ihostingenvironment中可以获取,对于预设值官方还做了判断封装,当然你可以重构它来封装自己的环境名判断。
http管道容器由三个扩展的方法来控制中间件的路由、挂载等等,分别是run, map, user。
a.run方法会使得可以使管道短路,顾名思义就是终结管道向下执行不会调用next()委托,所以run方法最好放在管道的最后来执行,如下面的代码:
/// <summary> /// 开发环境下配置http请求管道 /// </summary> /// <param name="app"></param> public void configuredevelopment(iapplicationbuilder app){ app.run(async (context) => { await context.response.writeasync("hello world - configuredevelopment"); }); app.run(async (context) => { await context.response.writeasync("hello world - configuredevelopment 不会被执行"); }); }
执行结果:
b.use不会主动短路整个http管道,但是也不会主动调用下一个中间件,必须自行调用await next.invoke(); 如果不使用这个方法去调用下一个中间件那么use此时的效果其实和run是相同的,我们来看正常的代码:
/// <summary> /// 开发环境下配置http请求管道 /// </summary> /// <param name="app"></param> public void configuredevelopment(iapplicationbuilder app){ var order =""; app.use(async (context, next) => { order = $"{order}|use start"; await next.invoke(); order = $"{order}|use end"; }); app.run(async context => { await context.response.writeasync($"{order}|run ext"); }); }
执行结果如下:
可以看到,use end并没有被执行到,因为在调用下一个中间件时采用了run,管道被终止了。
再来看看如果不显式调用next.invoke()时的代码:
/// <summary> /// 开发环境下配置http请求管道 /// </summary> /// <param name="app"></param> public void configuredevelopment(iapplicationbuilder app){ var order =""; app.use(async (context, next) => { order = $"{order}|use start"; //去掉显示调用下一个中间件 //await next.invoke(); order = $"{order}|use end"; await context.response.writeasync(order); }); app.run(async context => { await context.response.writeasync($"{order}|run ext"); }); }
其结果如下:
可以发现run这个中间件并没有被执行,而只是单纯的执行了use这个中间件。所以说 在不显式调用下一个中间件的情况下,效果和run时一样的会使管道短路。
c.map可以根据提供的url来路由中间件,如下代码判断url中访问"/test"时就会执行某个中间件逻辑:
/// <summary> /// 开发环境下配置http请求管道 /// </summary> /// <param name="app"></param> public void configuredevelopment(iapplicationbuilder app){ app.map("/test", handlemaptest); } /// <summary> /// maptest 处理方法 /// </summary> public void handlemaptest(iapplicationbuilder app){ app.run(async (context) => { await context.response.writeasync("handlemaptest handler"); }); }
结果如下:
如果访问/test就会执行相应的中间件,反之则不会执行。
mapwhen是map的一个条件判断的扩展方法,可以通过它来判断某个条件适合的时候执行某一个中间件,如:当携带某一个参数名称时,执行某一个中间件或者反之,代码如下:
/// <summary> /// 开发环境下配置http请求管道 /// </summary> /// <param name="app"></param> public void configuredevelopment(iapplicationbuilder app){ app.mapwhen(context => { return context.request.query.containskey("username"); }, handleusername); app.run(async context => { await context.response.writeasync("default ext"); }); } /// <summary> /// /// </summary> public void handleusername(iapplicationbuilder app){ app.run(async context => { await context.response.writeasync("username map"); }); }
结果如下:
map还可以进行嵌套路由中间件,这里不再描述,大家可以参看这里。
到此这篇关于asp.net core中间件与管道介绍的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持。
推荐阅读
-
ASP.NET Core应用中与第三方IoC/DI框架的整合
-
node.js中express中间件body-parser的介绍与用法详解
-
.net core 反射的介绍与使用
-
Asp.Net Core中服务的生命周期选项区别与用法详解
-
asp.net Core3.0区域与路由配置的方法
-
干货分享:ASP.NET CORE(C#)与Spring Boot MVC(JAVA)异曲同工的编程方式总结
-
Asp.Net Core 通过中间件防止图片盗链的实例
-
详解在ASP.NET Core中使用Angular2以及与Angular2的Token base身份认证
-
ASP.NET Core依赖注入系列教程之服务的注册与提供
-
(24)ASP.NET Core EF查询(查询的工作原理、跟踪与非跟踪查询)