Фильтры действий, или Как просто улучшить читаемость кода

Введение

В свободное от работы время я, как и многие другие разработчики, занимаюсь созданием своих приложений, чтобы опробовать самые последние технологии, создать что-то полезное для повседневного использования или просто открыть для себя что-то новое. Одним из таких проектов было веб-приложение, которое обрабатывало данные, введённые пользователем, и планировало выполнение задач, основанных на введённых данных. Так как личные проекты не ограничены во времени, то мне хотелось по возможности избавить проект от всех раздражающих моментов. И одним из таких моментов были повторяющиеся строчки кода в методах контроллера. Я начал искать решение этой проблемы и наткнулся на фильтры. Идея использования фильтров для поддержания чистоты кода показалась мне не только интересной и эффективной, но в то же время простой, поэтому я решил поделиться этой информацией с вами.

Роль фильтров в процессе обработки запроса

Сначала обсудим сами фильтры: для чего же они нужны? Фильтры позволяют выполнять определённые действия на различных стадиях обработки запроса в 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. Поэтому существует большая вероятность, что проблему можно решить другими, более привычными способами, например, через создание сервиса, в который можно вынести повторяющийся код. Большое же преимущество фильтров, как можно видеть выше, в том, что их просто реализовать и использовать. Поэтому о них стоит помнить как о несложных способах, которые можно всегда внедрить в проект, чтобы поддерживать код в чистоте.