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:see_no_evil::see_no_evil::see_no_evil: