在Asp.Net Core中使用ModelConvention實現全局過濾器隔離

從何說起這來自於我把項目遷移到Asp.Net Core的過程中碰到一個問題。在一個web程式中同時包含了MVC和WebAPI，現在需要給WebAPI部分單獨添加一個介面驗證過濾器，常規做法一般是寫好過濾器後給需要的控制器掛上這個標簽，高級點的做法是註冊一個全局過濾器，這樣可以避免每次手動添加同時 ...

從何說起

這來自於我把項目遷移到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