Источниками привязки можно управлять через набор атрибутов на параметрах действий. Допускается также создавать специальные средства привязки моделей, но эта тема выходит за рамки настоящей книги. В табл. 29.4 перечислены атрибуты, которые можно использовать для управления привязкой моделей.
Проверка достоверности происходит немедленно после привязки модели (явной и неявной). В то время как привязка модели добавляет ошибки в словарь ModelState из-за возникновения проблем преобразования, проверка достоверности добавляет ошибки в ModelState на основе бизнес-правил. Примерами бизнес-правил могут быть обязательные поля, строки с максимально разрешенной длиной или даты с заданным допустимым диапазоном.
Правила проверки достоверности устанавливаются через атрибуты проверки достоверности, встроенные или специальные. В табл. 29.5 кратко описаны наиболее часто используемые встроенные атрибуты проверки достоверности. Обратите внимание, что некоторые их них также служат аннотациями данных для формирования сущностей EF Core.
Можно также разработать специальные атрибуты проверки достоверности, но в книге данная тема не рассматривается.
Маршрутизация — это способ, которым ASP.NET Core сопоставляет HTTP-запросы с контроллерами и действиями (исполняемые
На заметку! Маршруты также применяются к страницам Razor, SignaIR, службам gRPC и т.д. В этой книге рассматриваются контроллеры стиля MVC и Web API.
Инфраструктура ASP.NET Core использует промежуточное ПО маршрутизации для сопоставления URL входящих запросов и для генерирования URL, отправляемых в ответах. Промежуточное ПО регистрируется в классе Startup, а конечные точки добавляются в классе Startup или через атрибуты маршрутов, как будет показано позже в главе.
Конечные точки маршрутизации состоят из шаблонов URL, включающих в себя переменные-заполнители (называемые
В дополнение к зарезервированным маркерам маршруты могут содержать специальные маркеры, которые отображаются (процессом привязки моделей) на параметры методов действий.
При определении маршрутов для служб ASP.NET метод действия не указывается. Вместо этого, как только контроллер обнаруживается, выполняемый метод действия базируется на методе HTTP запроса и назначениях методов HTTP методам действий. Детали будут приведены чуть позже.
При маршрутизации на основе соглашений (или традиционной маршрутизации) таблица маршрутов строится в методе UseEndpoints класса Startup. Метод MapControllerRoute добавляет конечную точку в таблицу маршрутов, указывая имя, шаблон URL и любые стандартные значения для переменных в шаблоне URL. В приведенном ниже примере кода заранее определенные заполнители {controller} и {action} ссылаются на контроллер и метод действия, содержащийся в данном контроллере. Заполнитель {id} является специальным и транслируется в параметр (по имени id) для метода действия. Добавление к маркеру маршрута знака вопроса указывает на его необязательность.
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
Запрашиваемый URL проверяется на соответствие с таблицей маршрутов. При наличии совпадения выполняется код, находящийся в этой конечной точке приложения. Примером URL, который мог бы обслуживаться таким маршрутом, является Car/Delete/5. В результате вызывается метод действия Delete класса контроллера CarController с передачей значения 5 в параметре id.
