Введение
В свободное от работы время я, как и многие другие разработчики, занимаюсь созданием своих приложений, чтобы опробовать самые последние технологии, создать что-то полезное для повседневного использования или просто открыть для себя что-то новое. Одним из таких проектов было веб-приложение, которое обрабатывало данные, введённые пользователем, и планировало выполнение задач, основанных на введённых данных. Так как личные проекты не ограничены во времени, то мне хотелось по возможности избавить проект от всех раздражающих моментов. И одним из таких моментов были повторяющиеся строчки кода в методах контроллера. Я начал искать решение этой проблемы и наткнулся на фильтры. Идея использования фильтров для поддержания чистоты кода показалась мне не только интересной и эффективной, но в то же время простой, поэтому я решил поделиться этой информацией с вами.
Роль фильтров в процессе обработки запроса
Сначала обсудим сами фильтры: для чего же они нужны? Фильтры позволяют выполнять определённые действия на различных стадиях обработки запроса в ASP.NET Core. Существуют следующие встроенные фильтры:
- Фильтры авторизации (Authorization filters) выполняются самыми первыми и определяют, может ли пользователь выполнить текущий запрос.
- Фильтры ресурсов (Resource filters) вызываются после фильтров авторизации и необходимы, как следует из названия, для обработки ресурсов. В частности, данный тип фильтров применяют в качестве механизма кэширования.
- Фильтры действий (Action Filters) выполняют указанные в них операции до и после выполнения метода контроллера, обрабатывающего запрос.
- Фильтры исключений (Exception Filters) используются для перехвата необработанных исключений, произошедших при создании контроллера, привязке модели и выполнении кода фильтров действий и методов контроллера.
- И наконец, самыми последними вызываются фильтры результатов (Result Filters), если метод контроллера был выполнен успешно. Данный тип фильтров чаще всего используется, чтобы модифицировать конечные результаты, например, мы можем создать свой заголовок ответа, в котором добавим нужную нам информацию.
Ниже представлена схема, которая показывает, в каком порядке вызываются фильтры в процессе обработки запроса:
Из всех фильтров наиболее полезным в повседневном программировании я нахожу фильтры действий. С их помощью можно вынести повторяющиеся операции и хранить их в одном месте. Далее я приведу примеры, как можно почистить код, но сперва расскажу о самих фильтрах действий.
Внутреннее устройство фильтров действий
Фильтры действий в ASP.NET
Интерфейс IActionFilter, который нужно реализовать, чтобы создать фильтр действий, существовал ещё в ASP.NET MVC. Он определяет методы OnActionExecuting, который вызывается перед выполнением метода контроллера, и OnActionExecuted, который вызывается сразу после. Ниже представлен пример простейшего фильтра действий, который выводит информацию во время отладки приложения до и после выполнения метода контроллера:
public class CustomActionFilter:IActionFilter { public void OnActionExecuting(ActionExecutingContext filterContext) { Debug.WriteLine("Before Action Execution"); } public void OnActionExecuted(ActionExecutedContext filterContext) { Debug.WriteLine("After Action Execution"); } }
Чтобы использовать вышеуказанный фильтр, его нужно зарегистрировать. Для этого в файле FilterConfig.cs, который находится в папке App_Start, следует добавить следующую строку:
public static void RegisterGlobalFilters(GlobalFilterCollection filters) { filters.Add(new HandleErrorAttribute()); filters.Add(new CustomActionFilter()); }
Но гораздо удобнее использовать фильтры как атрибуты. Для этих целей существует абстрактный класс ActionFilterAttribute, который унаследован от класса FilterAttribute, а также реализует интерфейсы IActionFilter и IResultFilter. Таким образом, наш класс можно переписать следующим образом:
public class CustomActionFilterAttribute:ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterContext) { Debug.WriteLine("Before Action Execution"); } public override void OnActionExecuted(ActionExecutedContext filterContext) { Debug.WriteLine("After Action Execution"); } }
Теперь, чтобы применить наш фильтр, мы добавляем его к методу контроллера следующим образом:
public class HomeController : Controller { [CustomActionFilter] public ActionResult Index() { return View(); } }
Этот способ также удобен тем, что мы можем применять фильтры к определённому методу или к контроллеру целиком, а не регистрировать их глобально.
Фильтры действий в ASP.NET Core
С появлением ASP.NET Core в фильтрах действий произошёл ряд изменений. Кроме интерфейса IActionFilter, теперь имеется ещё и IAsyncActionFilter, который определяет единственный метод OnActionExecutionAsync. Ниже приведён пример класса, реализующего интерфейс IAsyncActionFilter:
public class AsyncCustomActionFilterAttribute:Attribute, IAsyncActionFilter { public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next) { Debug.WriteLine("Before Action Execution"); await next(); Debug.WriteLine("After Action Execution"); } }
В качестве второго параметра методу передаётся делегат ActionExecutionDelegate, с помощью которого вызываются либо следующие по порядку фильтры действий, либо сам метод контроллера.
Применяют такой фильтр так же, как и синхронный:
public class HomeController : Controller { [AsyncCustomActionFilter] public ActionResult Index() { return View(); } }
Также изменения затронули абстрактный класс ActionFilterAttribute: теперь он наследуется от класса Attribute и реализует синхронные и асинхронные интерфейсы для фильтров действий (IActionFilter и IAsyncActionFilter) и для фильтров результатов (IResultFilter и IAsyncResultFilter), а также интерфейс IOrderedFilter.
Фильтры действий в действии
Перейдём непосредственно к случаям, когда лучше использовать фильтры действий. Возьмём, например, ситуацию, когда мы создаём веб-приложение и нам нужно сохранить данные, которые приложение получает с помощью метода POST. Допустим, мы ведём сведения о сотрудниках организации. Чтобы представить данные на сервере, мы используем следующий класс:
public class Employee { [Required(ErrorMessage = "First name is required")] public string FirstName { get; set; } [Required(ErrorMessage = "Last name is required")] public string LastName { get; set; } [AgeRestriction(MinAge = 18, ErrorMessage = "Date of birth is incorrect")] public DateTime DateOfBirth { get; set; } [StringLength(50, MinimumLength = 2)] public string Position { get; set; } [Range(45000, 200000)] public int Salary { get; set; } }
С помощью атрибутов валидации мы можем контролировать корректность введённых данных. Следует заметить, что атрибуты со статическими параметрами не всегда удобны для валидации данных как поля, указывающие на возраст и зарплату сотрудника, в примере выше. В таких случаях лучше создать отдельный сервис, который будет выполнять проверку таких полей, но в рамках этой статьи я решил воспользоваться исключительно атрибутами валидации.
После того как были реализованы методы POST и PUT, мы видим, что оба метода содержат повторяющиеся части кода:
[HttpPost] public IActionResult Post([FromBody] Employee value) { if (value == null) { return BadRequest("Employee value cannot be null"); } if (!ModelState.IsValid) { return BadRequest(ModelState); } // Perform save actions return Ok(); } [HttpPut] public IActionResult Put([FromBody] Employee value) { if (value == null) { return BadRequest("Employee value cannot be null"); } if (!ModelState.IsValid) { return BadRequest(ModelState); } // Perform update actions return Ok(); }
И здесь нам на помощь приходят фильтры действий. Создадим новый фильтр действий и перенесём в него повторяющиеся строки следующим образом:
public class EmployeeValidationFilterAttribute : ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext context) { var employeeObject = context.ActionArguments.SingleOrDefault(p => p.Value is Employee); if (employeeObject.Value == null) { context.Result = new BadRequestObjectResult("Employee value cannot be null"); return; } if (!context.ModelState.IsValid) { context.Result = new BadRequestObjectResult(context.ModelState); } } }
Теперь удаляем ставшие ненужными части кода и применяем созданный нами атрибут-фильтр:
public class EmployeeController : ControllerBase { [EmployeeValidationFilter] [HttpPost] public IActionResult Post([FromBody] Employee value) { // Perform save actions return Ok(); } [EmployeeValidationFilter] [HttpPut] public IActionResult Put([FromBody] Employee value) { // Perform update actions return Ok(); } }
Теперь код выглядит гораздо компактнее и красивее, но в нашем случае его ещё можно упростить: т.к. в контроллере всего 2 метода и оба используют один и тот же фильтр, то можно применить атрибут непосредственно к контроллеру:
[EmployeeValidationFilter] public class EmployeeController : ControllerBase { // Perform update actions }
Таким образом, с помощью фильтров действий мы вынесли повторяющиеся отрывки кода. Выглядит это просто. Но что нужно сделать, если в фильтр действий нам необходимо передать зависимость?
Разработчики часто сталкиваются с задачей, когда требуется добавить логирование для определённых методов. Поэтому попробуем добавить в фильтры действий средство логирования, которое будет записывать информацию перед выполнением методов POST или PUT контроллера и сразу после. Наш фильтр будет выглядеть следующим образом:
public class LoggingFilter: IActionFilter { private readonly ILogger _logger; public LoggingFilter(ILoggerFactory loggerFactory) { _logger = loggerFactory.CreateLogger<LoggingFilter>(); } public void OnActionExecuted(ActionExecutedContext context) { _logger.LogInformation($"{context.ActionDescriptor.DisplayName} executed"); } public void OnActionExecuting(ActionExecutingContext context) { _logger.LogInformation($"{context.ActionDescriptor.DisplayName} is executing"); } }
Теперь мы можем применить этот фильтр либо глобально, либо к конкретной области. Сначала попробуем зарегистрировать его глобально. Для этого нам в Startup.cs следует добавить следующие строки:
services.AddControllers(options => { options.Filters.Add<LoggingFilter>(); });
Если же нам нужно применить фильтр, например, к определённому методу контроллера, то следует его использовать вместе с ServiceFilterAttribute:
[HttpPost] [ServiceFilter(typeof(LoggingFilter))] public IActionResult Post([FromBody] Employee value)
ServiceFilterAttribute является фабрикой для других фильтров, реализующей интерфейс IFilterFactory и использующей IServiceProvider для получения нужного фильтра. Поэтому в Startup.cs нам необходимо зарегистрировать наш фильтр следующим образом:
services.AddSingleton<LoggingFilter>();
Запустив проект, мы сможем убедиться, что фильтр действий применился только к тем контроллерам и методам, у которых он указан в качестве атрибута.
Внедрение зависимостей в фильтры действий позволяет создавать удобные атрибуты-утилиты, которые можно легко переиспользовать. Ниже представлен пример фильтра, который проверяет наличие объекта в хранилище по Id и возвращает его, если он есть:
public class ProviderFilter : IActionFilter { private readonly IDataProvider _dataProvider; public ProviderFilter(IDataProvider dataProvider) { _dataProvider = dataProvider; } public void OnActionExecuted(ActionExecutedContext context) { } public void OnActionExecuting(ActionExecutingContext context) { object idValue; if (!context.ActionArguments.TryGetValue("id", out idValue)) { throw new ArgumentException("id"); } var id = (int)idValue; var result = _dataProvider.GetElement(id); if (result == null) { context.Result = new NotFoundResult(); } else { context.HttpContext.Items.Add("result", result); } } }
Применить этот фильтр можно так же, как и фильтр из предыдущего примера, с помощью ServiceFilterAttribute.
Фильтры действий раньше очень часто применяли, чтобы заблокировать контент для определённых браузеров на основе информации о User-Agent. На ранних этапах становления веб-разработки многие сайты создавались исключительно для наиболее популярных браузеров, остальные же считались запрещёнными. Сейчас данный подход является нежелательным, т.к. рекомендуется создавать такую HTML-разметку, которую смогло бы поддерживать большинство браузеров. Тем не менее, в некоторых случаях разработчику важно знать источник запроса. Ниже представлен пример получения User-Agent-информации в фильтре действий:
public class BrowserCheckFilter : IActionFilter { public void OnActionExecuting(ActionExecutingContext context) { var userAgent = context.HttpContext.Request.Headers[HeaderNames.UserAgent].ToString().ToLower(); // Detect if a user uses IE if (userAgent.Contains("msie") || userAgent.Contains("trident")) { // Do some actions } } public void OnActionExecuted(ActionExecutedContext context) { } }
Стоит, однако, заметить, что вышеуказанный метод имеет ещё один недостаток. Многие браузеры умеют прятать или подделывать значения, указанные в User-Agent, поэтому данный способ не является однозначно достоверным в определении типа пользовательского браузера.
Другой пример применения фильтров действий локализация. Создадим фильтр, который в зависимости от указанной культуры будет выводить дату в этой культуре. Ниже представлен код, который задаёт культуру текущего потока:
public class LocalizationActionFilterAttribute: ActionFilterAttribute { public override void OnActionExecuting(ActionExecutingContext filterContext) { var language = (string)filterContext.RouteData.Values["language"] ?? "en"; var culture = (string)filterContext.RouteData.Values["culture"] ?? "GB"; Thread.CurrentThread.CurrentCulture = CultureInfo.GetCultureInfo($"{language}-{culture}"); Thread.CurrentThread.CurrentUICulture = CultureInfo.GetCultureInfo($"{language}-{culture}"); } }
Следующим шагом следует добавить маршрутизацию, которая будет перенаправлять URL с данными культуры на наш контроллер:
endpoints.MapControllerRoute(name:"localizedRoute", pattern: "{language}-{culture}/{controller}/{action}/{id}", defaults: new { language = "en", culture = "GB", controller = "Date", action = "Index", id = "", });
Код выше создаёт маршрут с именем localizedRoute, у которого в шаблоне имеется параметр, отвечающий за локализацию. Значение по умолчанию для этого параметра en-GB.
Теперь создадим контроллер с именем DateController, который будет обрабатывать наш запрос, и представление, которое будет отображать локализованную дату. Код контроллера просто возвращает представлению текущую дату:
[LocalizationActionFilter] public class DateController : Controller { public IActionResult Index() { ViewData["Date"] = DateTime.Now.ToShortDateString(); return View(); } }
После того как пользователь перешёл по ссылке localhost:44338/Date, он увидит в браузере следующее:
На скриншоте выше текущая дата представлена с учётом локализации, заданной по умолчанию, т.е. с en-GB. Теперь, если пользователь перейдёт по ссылке, в которой будет явно указана культура, например, en-US, то он увидит следующее:
Таким образом, на этом примере мы можем увидеть, как сделать простую и быструю локализацию.
Заключение
В заключение следует заметить, что фильтры это лишь один из множества механизмов, предоставляемых ASP.NET. Поэтому существует большая вероятность, что проблему можно решить другими, более привычными способами, например, через создание сервиса, в который можно вынести повторяющийся код. Большое же преимущество фильтров, как можно видеть выше, в том, что их просто реализовать и использовать. Поэтому о них стоит помнить как о несложных способах, которые можно всегда внедрить в проект, чтобы поддерживать код в чистоте.
