.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

以上就是效果，同个这个个例，可以扩展实现很多的效果，例如写日志啊，语言环境的配置啊，等等。