從何說起
這來自于我把專案遷移到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寫博客真香
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/75359.html
標籤：.NET Core
上一篇：給你的 ASP.NET Core 程式插上 Feature Flag 的翅膀
下一篇：abp(net core)+easyui+efcore實作倉儲管理系統——ABP WebAPI與EasyUI結合增刪改查之七(三十三)