ASP.NET Core过滤器：身份验证、异常处理、模型验证等

一.用过滤器来偷懒

使用过滤器的好处是实现关注点分离，尽量偷懒，避免重复代码。
本文主要是介绍过滤器在webapi中的常用使用方法，但过滤器不是专属于webapi，甚至消息队列中都可以使用过滤器。
关于在asp.net core mvc中使用过滤器可以参考官方的英文文档或者国内的翻译文档
本文使用的代码：ZHS

二.用法举例说明

1.身份验证
这里不涉及到具体那种技术实现的身份验证，使用Microsoft.AspNetCore.Authorization自带的验证，可以看到，[Authorize()]会去执行对应的验证(此处500是因为没有具体的验证,无法执行)，而[AllowAnonymous]（允许任何人）和不加过滤器标签是可以访问的。如果使用了全局的身份验证过滤器，这里的[Authorize]和 [AllowAnonymous]是会覆盖掉之前的全局身份过滤器。
可以肯定的一点：合理使用全局和局部过滤器就可以使我们避免写过多的逻辑。

身份过滤器

Authorize()

AllowAnonymous

2.异常处理
使用异常过滤器避免自己手写一大堆try catch和记录日志，同时对特定错误进行特定的处理是很有效果的。除了必须的日志记录，友好的返回结果也是很有意义的，如果是mvc可以直接返回一个对用户友好的错误页面，webapi则看情况是否要返回错误信息。

异常处理

异常返回结果

需要注意一点： 在方法年内对异常进行try catch会覆盖掉异常过滤器的处理结果。如下图，在使用异常过滤器的控制器中try catch返回结果。

try catch 处理

try catch 结果

3.模型绑定
这是最常见也是最偷懒的地方，如果不使用过滤器，你控制器可能是如下图：

不用模型验证的处理

而现在结合 模型验证可以将逻辑转移到视图模型里面：

模型验证

而原来的过滤器就会瘦身：

不需要再写验证逻辑的控制器

由于模型验证是比较常用和具有普适性的，所以我在这里使用如下的全局过滤器（ 避免Startup膨胀，使用扩展方法）：

模型绑定的过滤器

全局调用

这样偷懒的结果也如预期：

数字是必需的

数字必须在1到1000之间

---

本文采用 知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议
转载请注明：作者 张蘅水