02 Модели и привязка данных

ASP.NET Core MVC — это фреймворк, который превращает сырые HTTP-запросы в структурированные объекты C#, позволяя разработчикам сосредоточиться на бизнес-логике, а не на рутинном парсинге данных. Центральным элементом этого процесса является Model Binding — механизм, автоматически мапящий данные из запроса (query string, формы, маршрута, тела) в параметры методов контроллера или свойства моделей. Однако за кажущейся простотой скрывается сложная система правил и расширяемости, требующая глубокого понимания. Например, когда пользователь отправляет форму с полем Email, фреймворк не просто присваивает значение свойству модели — он решает, как его тип, источник и валидация влияют на поведение приложения.

Каждый HTTP-запрос содержит данные, которые необходимо преобразовать в объекты, пригодные для обработки в коде. Представьте, что пользователь вводит URL вида /products/edit/5?color=red. Здесь 5 — идентификатор продукта в маршруте, color=red — параметр query string, а тело запроса (если это POST) может содержать форму с полями Name и Price. Model Binding автоматически извлекает эти значения и присваивает их свойствам модели, такой как ProductEditModel, объединяя данные из разных источников. Источники данных ранжируются по приоритету: тело запроса (для POST), маршрут, query string. Это важно, когда, например, параметр id присутствует и в маршруте, и в query string — будет использовано значение из маршрута.

Принцип работы Model Binding основан на поставщиках значений (Value Providers), которые извлекают данные из конкретных источников. Например, RouteValueProvider отвечает за параметры маршрута, QueryStringValueProvider — за query string, FormValueProvider — за данные формы. Когда действие контроллера принимает параметр, фреймворк последовательно опрашивает поставщиков, пока не найдет совпадение по имени. Для сложных объектов (например, Product) происходит рекурсивный поиск свойств: если в запросе есть поле Product.Name, оно будет привязано к свойству Name объекта Product.

Рассмотрим действие контроллера:

Здесь id берется из маршрута, category — явно указано брать из query string (атрибут [FromQuery]), а product — из тела запроса (по умолчанию для POST). Если в теле запроса есть поля Name и Price, они будут привязаны к соответствующим свойствам product. Однако если возникает конфликт имен (например, id присутствует и в маршруте, и в теле запроса), приоритет отдается источнику с более высоким рангом — в данном случае маршруту.

Особого внимания заслуживают сценарии с коллекциями и словарями. Если в запросе передаются несколько значений с одинаковым именем (например, tags=dotnet&tags=aspnet), Model Binding преобразует их в массив string[] tags. Для словарей используется нотация с индексами: user[0].Name=John&user[0].Age=30 превратится в Dictionary<int, User> user. Это удобно для динамических форм, где количество полей заранее неизвестно.

Однако автоматический биндинг не всегда идеален. Допустим, клиент отправляет дату в формате dd-MM-yyyy, а сервер ожидает yyyy-MM-dd. Без дополнительных преобразований возникнет ошибка привязки. Здесь на помощь приходят кастомные Model Binders, позволяющие переопределить логику парсинга. Например, можно создать биндер, который преобразует строку запроса в объект DateRange:

Этот биндер извлекает параметры start и end из запроса, парсит их в DateTime и создает объект DateRange. Чтобы использовать его, нужно зарегистрировать биндер в методе ConfigureServices:

Теперь, если действие принимает DateRange range, фреймворк будет использовать кастомную логику.

Model Binding неразрывно связан с валидацией данных. Даже если запрос успешно привязан к модели, это не гарантирует, что данные корректны. Например, поле Email может быть пустым или иметь неверный формат. Для решения этой задачи ASP.NET Core MVC использует атрибуты валидации из пространства имен System.ComponentModel.DataAnnotations, такие как [Required], [StringLength], [Range]. Эти атрибуты декларативно задают правила, которые проверяются автоматически при вызове ModelState.IsValid в контроллере.

Рассмотрим модель UserRegistrationModel:

При отправке формы с этими полями фреймворк проверит:

Email не пуст и соответствует формату адреса;

Password имеет длину от 6 до 100 символов;

ConfirmPassword совпадает с Password.

Если какое-то условие нарушено, свойство ModelState.IsValid вернет false, а ModelState заполнится ошибками. В контроллере это обрабатывается так:

Важно отметить, что валидация происходит на сервере, даже если клиентская часть (например, JavaScript) отключена. Это критично для безопасности: злоумышленник может отправить произвольные данные, минуя клиентские проверки.

Атрибуты валидации также поддерживают кастомные сообщения об ошибках, что улучшает UX. Например, [Required(ErrorMessage = "Поле {0} обязательно")] подставит имя свойства вместо {0}. Для сложных сценариев можно создавать пользовательские атрибуты валидации, наследуясь от ValidationAttribute:

Применение атрибута [AdultAge] к свойству BirthDate обеспечит проверку возраста.

Механизмы Model Binding и валидации тесно интегрированы. Например, если параметр действия имеет тип int, а в запросе передана строка "abc", Model Binding не сможет преобразовать значение, и ModelState отметит это как ошибку. Это исключает необходимость ручной проверки типов. Однако в некоторых случаях требуется тонкая настройка. Допустим, поле Price должно быть положительным числом. Атрибут [Range(1, double.MaxValue)] добавит проверку, но если клиент отправит строку "zero", Model Binding завершится ошибкой до этапа валидации. Чтобы обработать такие случаи, можно использовать пользовательские преобразователи типов (Type Converters) или кастомные Model Binders.

Пример: обработка нестандартного формата номера телефона. Если клиент отправляет номер в виде "+7 (999) 123-45-67", стандартный биндинг в string сохранит значение как есть, но для унификации данных может потребоваться удалить все нецифровые символы. Реализация этого в кастомном Model Binder гарантирует, что свойство Phone всегда содержит очищенный номер:

Теперь, даже если пользователь введет номер с пробелами или скобками, в модели будет храниться строка вида "79991234567".

Model Binding и валидация — не только удобство, но и вопросы безопасности. Например, overposting — атака, при которой злоумышленник отправляет поля, не предназначенные для редактирования (например, IsAdmin в модели пользователя). Чтобы предотвратить это, используйте атрибут [BindNever] или явно указывайте разрешенные поля с помощью [Bind]:

Это гарантирует, что только Name и Price будут привязаны, а остальные свойства (например, Id) останутся нетронутыми.

Для повышения производительности стоит учитывать, что Model Binding работает синхронно. Если модель содержит тяжелые ресурсы (например, загрузка файлов), рекомендуется использовать асинхронные методы или промежуточное ПО для потоковой обработки. Кроме того, избыточная валидация сложных моделей может замедлить приложение. В таких случаях помогает кэширование результатов валидации или разделение моделей на входные DTO и доменные объекты.