從何說(shuō)起

這來(lái)自于我把項(xiàng)目遷移到Asp.Net Core的過(guò)程中碰到一個(gè)問(wèn)題。在一個(gè)web程序中同時(shí)包含了MVC和WebAPI，現(xiàn)在需要給WebAPI部分單獨(dú)添加一個(gè)接口驗(yàn)證過(guò)濾器 IActionFilter ，常規(guī)做法一般是寫(xiě)好過(guò)濾器后給需要的控制器掛上這個(gè)標(biāo)簽，高級(jí)點(diǎn)的做法是注冊(cè)一個(gè)全局過(guò)濾器，這樣可以避免每次手動(dòng)添加同時(shí)代碼也更好管理。注冊(cè)全局過(guò)濾器的方式為：

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

但這樣做會(huì)帶來(lái)一個(gè)問(wèn)題，那就是MVC部分控制器也會(huì)受影響，雖然可以在過(guò)濾器中進(jìn)行一些判斷來(lái)區(qū)分哪些是MVC Controller哪些是API Controller，但是平白無(wú)故給MVC增加這么一個(gè)沒(méi)用的Filter，反正我是不能忍，所以尋找有沒(méi)有更好的辦法來(lái)實(shí)現(xiàn)這個(gè)功能。

于是ModelConvention（可以翻譯為模型約定）閃亮登場(chǎng)。

先認(rèn)識(shí)下ApplicationModel

看一下官方文檔是怎么描述應(yīng)用程序模型（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.

簡(jiǎn)單一點(diǎn)說(shuō)，ApplicationModel描述了MVC應(yīng)用中的各種對(duì)象和行為，這些內(nèi)容包含Application、Controller、Action、Parameter、Router、Page、Property、Filter等等，而Asp.Net Core框架本身內(nèi)置一套規(guī)則（Convention）用來(lái)處理這些模型，同時(shí)也提供了接口給我們自定義約定來(lái)擴(kuò)展模型以實(shí)現(xiàn)更符合需要的應(yīng)用。

和應(yīng)用程序模型有關(guān)的類都定義在命名空間 Microsoft.AspNetCore.Mvc.ApplicationModels 中，這些模型通過(guò) IApplicationModelProvider 構(gòu)建出來(lái)，Asp.Net Core框架提供的默認(rèn)Provider是 DefaultApplicationModelProvider 。我們可以編輯這些模型，從而更改它的表現(xiàn)行為，這就要借助它的ModelConvention來(lái)實(shí)現(xiàn)。

ModelConvention

ModelConvention定義了操作模型的入口，又或者說(shuō)是一種契約，通過(guò)它我們可以對(duì)模型進(jìn)行修改，常用的Convention包括：

• IApplicationModelConvention
• IControllerModelConvention
• IActionModelConvention
• IParameterModelConvention
• IPageRouteModelConvention

這些接口提供了一個(gè)共同的方法 Apply ，方法參數(shù)是各自的應(yīng)用程序模型，以 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.
  //
  // 參數(shù):
  // controller:
  //  The Microsoft.AspNetCore.Mvc.ApplicationModels.ControllerModel.
  void Apply(ControllerModel controller);
 }
}

從接口摘要可以看到，這個(gè)接口允許自定義 ControllerModel 對(duì)象，而如何自定義內(nèi)容正是通過(guò) Apply 方法來(lái)實(shí)現(xiàn)，這個(gè)方法提供了當(dāng)前 ControllerModel 對(duì)象的實(shí)例，我們可以在它身上獲取到的東西實(shí)在太多了，看看它包含些什么：

有了這些，我們可以做很多很靈活的操作，例如通過(guò)設(shè)置 ControllerName 字段強(qiáng)制更改控制器的名稱讓程序中寫(xiě)死的控制器名失效，也可以通過(guò) Filters 字段動(dòng)態(tài)更新它的過(guò)濾器集合，通過(guò) RouteValues 來(lái)更改路由規(guī)則等等。

說(shuō)到這里，很多人會(huì)覺(jué)得這玩意兒和自定義過(guò)濾器看起來(lái)差不多，最開(kāi)始我也這么認(rèn)為，但經(jīng)過(guò)實(shí)際代碼調(diào)試我發(fā)現(xiàn)它的生命周期要比過(guò)濾器早的多，或者說(shuō)根本無(wú)法比較， 這個(gè)家伙只需要在應(yīng)用啟動(dòng)時(shí)執(zhí)行一次并不用隨著每次請(qǐng)求而執(zhí)行 。也就是說(shuō)，它的執(zhí)行時(shí)間比激活控制器還要早，那時(shí)候根本沒(méi)有過(guò)濾器什么事兒，它的調(diào)用是發(fā)生在 app.UseEndpoints() 。

回到最開(kāi)始的需求?；谏厦娴慕榻B，我們可以自定義如下的約定：

 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());
   }
  }
 }

上面的主要思路就是通過(guò)判斷控制器本身的過(guò)濾器集合是否包含 ApiControllerAttribute 來(lái)識(shí)別是否API Controller，如果是API Controller并且沒(méi)有標(biāo)記過(guò) AccessControlAttribute 的話就新建一個(gè)實(shí)例加入進(jìn)去。

那么如何把這個(gè)約定注冊(cè)到應(yīng)用中呢？在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; }

通過(guò)操作它就能把自定義約定注入進(jìn)去：

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

細(xì)心的人會(huì)發(fā)現(xiàn)，Conventions是一個(gè) IApplicationModelConvention 類型的集合，而我們自定義的Convention是一個(gè) IControllerModelConvention ，正常來(lái)說(shuō)應(yīng)該會(huì)報(bào)錯(cuò)才對(duì)？原因是Asp.Net Core的DI框架幫我們提供了一系列擴(kuò)展方法來(lái)簡(jiǎn)化Convention的添加不用自己再去轉(zhuǎn)換：

通過(guò)代碼調(diào)試發(fā)現(xiàn)，應(yīng)用啟動(dòng)時(shí)遍歷了系統(tǒng)中的所有控制器去執(zhí)行Apply操作，那么通過(guò) IApplicationModelConvention 一樣也能實(shí)現(xiàn)這個(gè)功能，因?yàn)樗锩姘丝刂破骷希?/p>

 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());
    }
   }
  }
 }

再改進(jìn)一下

實(shí)際開(kāi)發(fā)中我的AccessControlFilter需要通過(guò)構(gòu)造函數(shù)注入業(yè)務(wù)接口，類似于這樣：

 public class AccessControlFilter : IActionFilter
 {
  private IUserService _userService;

  public AccessControlFilter(IUserService service)
  {
   _userService = service;
  }

  public void OnActionExecuting(ActionExecutingContext context)
  {
    //模擬一下業(yè)務(wù)操作
    //var user=_userService.GetById(996);
    //.......
  }

  public void OnActionExecuted(ActionExecutedContext context)
  {
  }
 }

如何優(yōu)雅的在Convention中使用DI自動(dòng)注入呢？Asp.Net Core MVC框架提供的 ServiceFilter 可以解決這個(gè)問(wèn)題， ServiceFilter 本身是一個(gè)過(guò)濾器，它的不同之處在于能夠通過(guò)構(gòu)造函數(shù)接收一個(gè)Type類型的參數(shù)，我們可以在這里把真正要用的過(guò)濾器傳進(jìn)去，于是上面的過(guò)濾器注冊(cè)過(guò)程演變?yōu)椋?/p>

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

當(dāng)然了，要從DI中獲取這個(gè)filter實(shí)例，必須要把它注入到DI容器中：

 services.AddScoped<AccessControlFilter>();

至此，大功告成，繼續(xù)愉快的CRUD。

突然想起來(lái)我上篇文章提到的擴(kuò)展DI屬性注入功能估計(jì)也能通過(guò)這個(gè)玩意實(shí)現(xiàn)，eeeeeee...有空了試一下。

總結(jié)

總體來(lái)說(shuō)，我通過(guò)曲線救國(guó)的方式實(shí)現(xiàn)了全局過(guò)濾器隔離，雖然去遍歷目標(biāo)控制器再手動(dòng)添加Filter的方式?jīng)]有那種一行代碼就能實(shí)現(xiàn)的方式優(yōu)雅，但我大體來(lái)說(shuō)還算滿意，是目前能想到的最好辦法。我估摸著， options.Filters.Add(xxx) 也是在框架某個(gè)時(shí)候一個(gè)個(gè)把xxx丟給各自主人的，瞎猜的，說(shuō)錯(cuò)不負(fù)責(zé)~hhhh:see_no_evil::see_no_evil::see_no_evil:

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持我們。