标签：

原文:在Asp.Net Core中使用ModelConvention实现全局过滤器断绝

从何说起

这来自于我把项目迁移到Asp.Net Core的过程中碰到一个问题。在一个web措施中同时包罗了MVC和WebAPI，此刻需要给WebAPI部分单独添加一个接口验证过滤器IActionFilter，通例做法一般是写好过滤器后给需要的控制器挂上这个标签，高级点的做法是注册一个全局过滤器，这样可以制止每次手动添加同时代码也更好打点。注册全局过滤器的方法为：

services.AddMvc(options => { options.Filters.Add(typeof(AccessControlFilter)); });

但这样做会带来一个问题，那就是MVC部分控制器也会受影响，虽然可以在过滤器中进行一些判断来区分哪些是MVC Controller哪些是API Controller，但是平白无故给MVC增加这么一个没用的Filter，横竖我是不能忍，所以寻找有没有更好的步伐来实现这个成果。
于是ModelConvention（可以翻译为模型约定）闪亮登场。

先认识下ApplicationModel

看一下官方文档是怎么描述应用措施模型（ApplicationModel）的：

ASP.NET Core MVC defines an application model representing the components of an MVC app. You can read and manipulate this model to modify how MVC elements behave. By default, MVC follows certain conventions to determine which classes are considered to be controllers, which methods on those classes are actions, and how parameters and routing behave. You can customize this behavior to suit your app‘s needs by creating your own conventions and applying them globally or as attributes.

简单一点说，ApplicationModel描述了MVC应用中的各类东西和行为，这些内容包罗Application、Controller、Action、Parameter、Router、Page、Property、Filter等等，而Asp.Net Core框架自己内置一套法则（Convention）用来措置惩罚惩罚这些模型，同时也供给了接口给我们自界说约定来扩展模型以实现更切合需要的应用。

和应用措施模型有关的类都界说在定名空间Microsoft.AspNetCore.Mvc.ApplicationModels中，这些模型通过IApplicationModelProvider 构建出来，Asp.Net Core框架供给的默认Provider是DefaultApplicationModelProvider。我们可以编纂这些模型，从而变动它的表示行为，这就要借助它的ModelConvention来实现。

ModelConvention

ModelConvention界说了操纵模型的入口，又或者说是一种契约，通过它我们可以对模型进行改削，常用的Convention包孕：

IApplicationModelConvention

IControllerModelConvention

IActionModelConvention

IParameterModelConvention

IPageRouteModelConvention

这些接口供给了一个配合的要领Apply，要领参数是各自的应用措施模型，以IControllerModelConvention为例看一下它的界说：

namespace Microsoft.AspNetCore.Mvc.ApplicationModels { // // 摘要: // Allows customization of the Microsoft.AspNetCore.Mvc.ApplicationModels.ControllerModel. // // 言论： // To use this interface, create an System.Attribute class which implements the // interface and place it on a controller class. Microsoft.AspNetCore.Mvc.ApplicationModels.IControllerModelConvention // customizations run after Microsoft.AspNetCore.Mvc.ApplicationModels.IApplicationModelConvention // customizations and before Microsoft.AspNetCore.Mvc.ApplicationModels.IActionModelConvention // customizations. public interface IControllerModelConvention { // // 摘要: // Called to apply the convention to the Microsoft.AspNetCore.Mvc.ApplicationModels.ControllerModel. // // 参数: // controller: // The Microsoft.AspNetCore.Mvc.ApplicationModels.ControllerModel. void Apply(ControllerModel controller); } }

从接口摘要可以看到，这个接口允许自界说ControllerModel东西，而如何自界说内容正是通过Apply要领来实现，这个要领供给了当前ControllerModel东西的实例，我们可以在它身上获取到的对象实在太多了，看看它包罗些什么：

有了这些，我们可以做很多很灵活的操纵，例如通过设置ControllerName字段强制变动控制器的名称让措施中写死的控制器名掉效，也可以通过Filters字段动态更新它的过滤器调集，通过RouteValues来变动路由法则等等。

说到这里，很多人会感受这玩意儿和自界说过滤器看起来差不久不多，最开始我也这么认为，但颠末实际代码调试我发明它的生命周期要比过滤器早的多，或者说根柢无法对照，这个家伙只需要在应用启动时执行一次并不用跟着每次请求而执行。也就是说，它的执行时间比激活控制器还要早，那时候根柢没有过滤器什么事儿，它的挪用是产生在app.UseEndpoints()。