HTTP Request 数据入关

现在的项目都推崇前后端分离，把业务逻辑更多的放在后端服务器上，一方面出于现在前端种类比较多，各种前端（web,desktop,pad,mobile）可以重用业务逻辑，二方面出于安全考虑。那么前端（不一定是客户端，处于前端的服务）需要数据就必须发动Http 请求，HTTP请求的数据是怎么进入到我们的controller 的Action里的？

模型绑定：HTTP请求里带的数据映射到Action 参数的过程。

下面这些特性都是用在Action 参数前的特性，让框架知道怎么绑定。

[FromHeader] 从HTTP 请求的header中

[FromQuery] 从http请求的查询字符串中，也就是? 后的一堆数据中

[FromServices] 从依赖容器，这个为什么没通过构造注入呢，因为构造注入的是一个对象用的很多，如果只是一个方法用可以这样方法注入。

[FromRoute] 从路由中获取参数

[FromForm] 从表单获取参数

[FromBody] 从HTTP请求消息的正文获取参数

另外可以指定[BindRequired] 必须绑定到值，要不引发ModelState 错误，

还可以[BindNever] 忽略次参数的绑定。

模型验证：数据被绑定时候会发生模型验证

模型验证不通过会返回400 BadRequest 给前端，还没进入我们的Action里面的逻辑，就被框架挡回去了，框架还是做了不少事情，前提是controller配置了[ApiController]特性。

 一：DataAnnotation 验证：引入System.ComponentModel.DataAnnotations 命名空间

一般所验证的对象有很多属性，这里验证分几步，逐步升级的过程

 1. 属性值强类型验证：属性本身就自带验证，比如属性是Int，你给个字符那么肯定通不过，属性是Datetime,你给个不能转换的时间，这个时候不用画蛇添足的在上面加比如时间格式的正则表达式，多用系统的强类型，.netcore框架还是很智能的。

 2. 内置特性验证：属性值强类型验证通过后，还可以给属性上添加比如最大值，最小值，范围值等内置特性验证。

 3. 业务逻辑验证：继续升级验证规则，当内置特性不够用后，还可以自定义特性，或者DTO对象继承 IValidatableObject 对象。

     1.创建新的特性，继承自ValidationAttribute. 然后给需要的数据加上特性。

     2. dto对象继承自IVaildatableObject 接口。

二：FluentValide 验证，具体没多用过

过滤器: 中间件都走完了之后进入Action前后的一段逻辑。

5种类型的过滤器：

 Autorization, Resouce, Exception Action Result.

1. 用户发起一个请求；
2. 请求经过Asp.NetCore应用程序的所有的中间件管道；
3. 管道走完之后进入MVC的第一个过滤器：授权过滤器（单向）；
4. 授权通过之后进入资源过滤器的前置方法；
5. 将异常过滤器加入使用，后续有异常可以进行捕获，之前如果发生异常不能捕获；（想象成从这里开了大try-catch，只能捕获Action中的，比如ResultFilter中的捕获不了，有点意外）
6. 进行数据模型绑定，比如参数通过数据模型绑定传参；
7. 进入Action过滤器前置方法；
8. 执行Action方法具体逻辑；
9. 进入Action过滤器后置方法；
10. 进入Result过滤器前置方法；
11. 渲染Result结果；
12. 进入Result过滤器后置方法；
13. 进入资源过滤器的后置方法；
14. 进入中间件管道返回；
15. 最后将响应结果展现给用户；

过滤器的注册范围

除了上面的全局注册，实现了特性的过滤器还可以以特性的方式标注在控制器或对应Action方法上：

   全局注册：针对系统中所有过滤器都有效；这种过滤器可以不继承特性。

   标注在控制器上(Controller)：对标注控制器中所有Action方法都有效；

   标注在Action上：只针对对应的Action有效；

继续处理器下回下文待续...