Язык программирования C#9 и платформа .NET5

  }
}
  
Атрибут Bind
 
Атрибут 
Bind
 в HTTP-методах POST позволяет ограничить свойства, которые участвуют в привязке модели, или установить префикс для имени в парах "имя-значение". Ограничение свойств, которые могут быть привязаны, снижает опасность атак избыточной отправкой (over-posting attack). Если атрибут 
Bind
 помещен на ссылочный параметр, то значения будут присваиваться через привязку модели только тем полям, которые перечислены в списке 
Include
. Если атрибут 
Bind
 не используется, тогда привязку допускают все поля.
В следующем примере метода действия 
Create()
 все поля экземпляра 
Car
 доступны для привязки, поскольку атрибут 
Bind
 не применяется:
[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Create(Car car)
{
  if (ModelState.IsValid)
 
  {
    // Добавить запись.
  }
    // Позволить пользователю повторить попытку.
}
Пусть в ваших бизнес-требованиях указано, что методу 
Create()
 разрешено обновлять только поля 
PetName
 и 
Color
. Добавление атрибута 
Bind
 (как показано в примере ниже) ограничивает свойства, участвующие в привязке, и инструктирует средство привязки моделей о том, что остальные свойства должны игнорироваться.
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(
<b>[Bind(nameof(Car.PetName),nameof(Car.Color))]Car car)</b>
{
  if (ModelState.IsValid)
 
  {
    // Сохранить данные.
  }
    // Позволить пользователю повторить попытку.
}
Атрибут 
Bind
 можно также использовать для указания префикса имен свойств. Если имена в парах "имя-значение" имеют префикс, добавленный при их отправке методу действия, тогда атрибут 
Bind
 применяется для информирования средства привязки моделей о том, как сопоставлять эти имена со свойствами типа. Код в следующем примере устанавливает префикс для имен и позволяет привязывать все свойства:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create(
[Bind<b>(Prefix=&quot;MakeList&quot;)</b>]Car car)
{
  if (ModelState.IsValid)
 
  {
    // Сохранить данные.
  }
}
  
Управление источниками привязки моделей в 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.
В дополнение к зарезервированным маркерам маршруты могут содержать специальные маркеры, которые отображаются (процессом привязки моделей) на параметры методов действий.