.net core的在初始化数据的拦截处理
本人初接触 .net core 如有不对的地方,请大家随时指正,共同学习。
首先说明,此案例是基于.net core1.0版本的,对于2.0好多的功能已经升级,例如:一些常用的dll已经在框架中存在,不需要自己引入等等。
首先说明一下.net core的框架原理
在说明.net core之前,我们先来回顾一下原来的,net core的机制。原来的.net 是通过管道来进行处理,如下图(盗用了网上的一张图片)
简单说明一下流程就是:(参考:http://www.cnblogs.com/fsjohnhuang/archive/2012/07/12/2587658.html#a1)
当用户发出请求的时候,Http Request传到工作进程(IIS5.x为aspnet_wp.exe,IIS6.x和IIS7.x为w3wp.exe)后,工作进程实例中通过ISAPIRuntime(主要作用是调用一些非托管代码生成HttpWorkerRequest对象,HttpWorkerRequest对象包含当前请求的所有信息,然后传递给HttpRuntime)传递HttpWorkerRequest对象给HttpRuntime并调用HttpRuntime的ProcessRequest方法,HttpRuntime为管道模型的入口此时正式进入管道模型。
HttpRuntime根据HttpWorkerRequest对象生成HttpContext,然后经过HttpApplicationFactory 生成HttpApplication,HttpApplication对象包含多个HttpModule对象(一般情况,有22个module对象,是框架自动生成的,当然你可以自己添加module来进行一些特殊情况的处理)。HttpModule是一个HTTP请求的“必经之路”,HttpModule事件的处理过程就是一个事件订阅模型,不懂这个模型的最好先了解一下。然后经过一系列处理最终返回给客户端。
下面是.net core 的处理模型,对于我个人来说,总觉得思想与管道还是有些一致的,但是对于具体的实现来说,简单了不少。在上面说过了,在.net core1.0中,基本上所有的.dll都需要用nuget自己手动的引用,就比如说连session都需要自己手动进行引用,其他的就更不用说了。
首先看一下 .net core生成的项目的模样
通过上图,我们能够看到,原来的引用变成了现在的依赖项,.net core其中很大的改变就是将所有的引用都是通过反射的形式获取加载的。还有一个地方就是,之前的web.config这种类型的文件已经不存在了,全都都是利用.json格式的文件存储的。
下面,就开始说明拦击的处理了:在此,说明一下,这里的处理基本上都是相对于全局的处理。
在此说明一下.net core与.net 的不同之处,上面简单介绍了管道处理模型,在.net core中已经不存在管道处理模型了,所有的处理都是通过中间件(Middleware)来进行处理的
上面的代码,是我新建的一个中间件,这个类中,必须要实现一个带有RequestDelegate的构造函数,还有实现 public async Task Invoke(HttpContext httpContext)方法。在这里,说明一下代码的逻辑,如果地址为”/middleware“,则直接返回,否则继续下一个
首先,我们找到StartUp文件,在里面可以找到Configure()方法,我们接下来说的东西,都是在这个方法里发生的,首先说明一下 app.UseMvc是这里的事件终结者。
在这里添加处理的方法有三种 app.run(), app.Use(),app.Map()/app.MapWhen()
在这里我们是新建的类,所以通过use来实现的。
调用如下:
下面运行代码,看看效果
正常访问
访问/home/index
访问/middleware
以上就是效果,同个这个个例,可以扩展实现很多的效果,例如写日志啊,语言环境的配置啊,等等。