}
}
Атрибут Bind
Атрибут Bind в HTTP-методах POST позволяет ограничить свойства, которые участвуют в привязке модели, или установить префикс для имени в парах "имя-значение". Ограничение свойств, которые могут быть привязаны, снижает опасность атак избыточной отправкой (over-posting attack). Если атрибут Bind помещен на ссылочный параметр, то значения будут присваиваться через привязку модели только тем полям, которые перечислены в списке Include. Если атрибут Bind не используется, тогда привязку допускают все поля.
В следующем примере метода действия Create() все поля экземпляра Car доступны для привязки, поскольку атрибут Bind не применяется:
[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Create(Car car)
{
if (ModelState.IsValid)
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
{
// Добавить запись.
}
// Позволить пользователю повторить попытку.
}
Пусть в ваших бизнес-требованиях указано, что методу Create() разрешено обновлять только поля PetName и Color. Добавление атрибута Bind (как показано в примере ниже) ограничивает свойства, участвующие в привязке, и инструктирует средство привязки моделей о том, что остальные свойства должны игнорироваться.
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(
<b>[Bind(nameof(Car.PetName),nameof(Car.Color))]Car car)</b>
{
if (ModelState.IsValid)
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
{
// Сохранить данные.
}
// Позволить пользователю повторить попытку.
}
Атрибут Bind можно также использовать для указания префикса имен свойств. Если имена в парах "имя-значение" имеют префикс, добавленный при их отправке методу действия, тогда атрибут Bind применяется для информирования средства привязки моделей о том, как сопоставлять эти имена со свойствами типа. Код в следующем примере устанавливает префикс для имен и позволяет привязывать все свойства:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(
[Bind<b>(Prefix="MakeList")</b>]Car car)
{
if (ModelState.IsValid)
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
{
// Сохранить данные.
}
}
Управление источниками привязки моделей в ASP.NET Core
Источниками привязки можно управлять через набор атрибутов на параметрах действий. Допускается также создавать специальные средства привязки моделей, но эта тема выходит за рамки настоящей книги. В табл. 29.4 перечислены атрибуты, которые можно использовать для управления привязкой моделей.
![]()
Проверка достоверности моделей
Проверка достоверности происходит немедленно после привязки модели (явной и неявной). В то время как привязка модели добавляет ошибки в словарь ModelState из-за возникновения проблем преобразования, проверка достоверности добавляет ошибки в ModelState на основе бизнес-правил. Примерами бизнес-правил могут быть обязательные поля, строки с максимально разрешенной длиной или даты с заданным допустимым диапазоном.
Правила проверки достоверности устанавливаются через атрибуты проверки достоверности, встроенные или специальные. В табл. 29.5 кратко описаны наиболее часто используемые встроенные атрибуты проверки достоверности. Обратите внимание, что некоторые их них также служат аннотациями данных для формирования сущностей EF Core.
![]()
Можно также разработать специальные атрибуты проверки достоверности, но в книге данная тема не рассматривается.
Маршрутизация
Маршрутизация — это способ, которым ASP.NET Core сопоставляет HTTP-запросы с контроллерами и действиями (исполняемые конечные точки) в вашем приложении взамен старого процесса отображения URL на структуру файлов проекта, принятого в Web Forms. Она также предлагает механизм для создания URL изнутри приложения на основе таких конечных точек. Конечная точка в приложении MVC или Web API состоит из контроллера, действия (только MVC), метода HTTP и необязательных значений (называемых значениями маршрута).
На заметку! Маршруты также применяются к страницам Razor, SignaIR, службам gRPC и т.д. В этой книге рассматриваются контроллеры стиля MVC и Web API.
Инфраструктура ASP.NET Core использует промежуточное ПО маршрутизации для сопоставления URL входящих запросов и для генерирования URL, отправляемых в ответах. Промежуточное ПО регистрируется в классе Startup, а конечные точки добавляются в классе Startup или через атрибуты маршрутов, как будет показано позже в главе.
Шаблоны URL и маркеры маршрутов
Конечные точки маршрутизации состоят из шаблонов URL, включающих в себя переменные-заполнители (называемые маркерами) и литералы, которые помещены в упорядоченную коллекцию, известную как таблица маршрутов. Каждая запись в ней определяет отличающийся шаблон URL, предназначенный для сопоставления. Заполнители могут быть специальными переменными или браться из заранее определенного списка. Зарезервированные маркеры маршрутов перечислены в табл. 29.6.
![]()
В дополнение к зарезервированным маркерам маршруты могут содержать специальные маркеры, которые отображаются (процессом привязки моделей) на параметры методов действий.
