在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()。

回到最開始的需求。基於上面的介紹，咱們能夠自定義以下的約定：

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丟給各自主人的，瞎猜的，說錯不負責~hhhh🙈🙈🙈

第一次用markdown寫博客真香