從何說起

這來自于我把項目遷移到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()。

回到最開始的需求。基于上面的介紹，我們可以自定義如下的約定：

public class ApiControllerAuthorizeConvention : IControllerModelConvention{public void Apply(ControllerModel controller){if (controller.Filters.Any(x => x is ApiControllerAttribute) && !controller.Filters.Any(x => x is AccessControlFilter)){controller.Filters.Add(new AccessControlAttribute());}}}

上面的主要思路就是通過判斷控制器本身的過濾器集合是否包含ApiControllerAttribute來識別是否API Controller，如果是API Controller并且沒有標記過AccessControlAttribute的話就新建一個實例加入進去。

那么如何把這個約定注冊到應用中呢？在Microsoft.AspNetCore.Mvc.MvcOptions中提供了Conventions屬性：

//// 摘要:// Gets a list of Microsoft.AspNetCore.Mvc.ApplicationModels.IApplicationModelConvention// instances that will be applied to the Microsoft.AspNetCore.Mvc.ApplicationModels.ApplicationModel// when discovering actions.public IList<IApplicationModelConvention> Conventions { get; }

通過操作它就能把自定義約定注入進去：

services.AddMvc(options =>{options.Conventions.Add(new ApiControllerAuthorizeConvention());})

細心的人會發現，Conventions是一個IApplicationModelConvention類型的集合，而我們自定義的Convention是一個IControllerModelConvention，正常來說應該會報錯才對？原因是Asp.Net Core的DI框架幫我們提供了一系列擴展方法來簡化Convention的添加不用自己再去轉換：

通過代碼調試發現，應用啟動時遍歷了系統中的所有控制器去執行Apply操作，那么通過IApplicationModelConvention一樣也能實現這個功能，因為它里面包含了控制器集合：

public class ApiControllerAuthorizeConvention : IApplicationModelConvention{public void Apply(ApplicationModel application){foreach (var controller in application.Controllers){if (controller.Filters.Any(x => x is ApiControllerAttribute) && !controller.Filters.Any(x => x is AccessControlFilter)){controller.Filters.Add(new AccessControlFilter());}}}}

再改進一下

實際開發中我的AccessControlFilter需要通過構造函數注入業務接口，類似于這樣：

public class AccessControlFilter : IActionFilter{private IUserService _userService;public AccessControlFilter(IUserService service){_userService = service;}public void OnActionExecuting(ActionExecutingContext context){//模擬一下業務操作//var user=_userService.GetById(996);//.......}public void OnActionExecuted(ActionExecutedContext context){}}

如何優雅的在Convention中使用DI自動注入呢？Asp.Net Core MVC框架提供的ServiceFilter可以解決這個問題，ServiceFilter本身是一個過濾器，它的不同之處在于能夠通過構造函數接收一個Type類型的參數，我們可以在這里把真正要用的過濾器傳進去，于是上面的過濾器注冊過程演變為：

controller.Filters.Add(new ServiceFilterAttribute(typeof(AccessControlFilter)));

當然了，要從DI中獲取這個filter實例，必須要把它注入到DI容器中：

services.AddScoped<AccessControlFilter>();

至此，大功告成，繼續愉快的CRUD。

突然想起來我上篇文章提到的擴展DI屬性注入功能估計也能通過這個玩意實現，eeeeeee...有空了試一下。

總結

總體來說，我通過曲線救國的方式實現了全局過濾器隔離，雖然去遍歷目標控制器再手動添加Filter的方式沒有那種一行代碼就能實現的方式優雅，但我大體來說還算滿意，是目前能想到的最好辦法。我估摸著，options.Filters.Add(xxx)也是在框架某個時候一個個把xxx丟給各自主人的，瞎猜的，說錯不負責

總結

以上是生活随笔為你收集整理的在Asp.Net Core中使用ModelConvention实现全局过滤器隔离的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。