раскрыты в главе 31.
Соглашения по конфигурации
ASP.NET MVC и ASP .NET Web API сократили объем необходимой конфигурации за счет введения ряда соглашений. В случае соблюдения таких соглашений уменьшается объем ручного (или шаблонного) конфигурирования, но при этом разработчики обязаны знать соглашения, чтобы использовать их в своих интересах. Двумя главными видами соглашений являются соглашения об именовании и структура каталогов.
Соглашения об именовании
В ASP.NET Core существует множество соглашений об именовании, предназначенных для приложений MVC и API. Например, контроллеры обычно содержат суффикс Controller в своих именах (скажем, HomeController) и вдобавок порождены от класса Controller (или ControllerBase). При доступе через маршрутизацию суффикс Controller отбрасывается. При поиске представлений контроллера отправной точкой поиска будет имя контроллера без суффикса. Такое соглашение об отбрасывании суффикса встречается повсюду в ASP.NET Core. В последующих главах вы встретите немало примеров.
Еще одно соглашение об именовании применяется относительно местоположения и выбора представлений. По умолчанию метод действия (в приложении MVC) будет визуализировать представление с таким же именем, как у метода. Шаблоны редактирования и отображения именуются в соответствии с классом, который они визуализируют в представлении. Описанное стандартное поведение может быть изменено, если того требует ваше приложение. Все это будет дополнительно исследоваться при построении приложения AutoLot.Mvc.
Структура каталогов
Существует несколько соглашений о папках, которые вы должны понимать, чтобы успешно создавать веб-приложения и службы ASP.NET Core.
Папка Controllers
По соглашению папка Controllers является тем местом, где реализации ASP.NET Core MVC и API (а также механизм маршрутизации) ожидают обнаружить контроллеры для вашего приложения.
Папка Views
В папке Views хранятся представления для приложения. Каждый контроллер получает внутри главной папки Views собственную папку с таким же именем, как у контроллера (исключая суффикс Controller). По умолчанию методы действий будут визуализировать представления из папки своего контроллера. Например, папка Views/Home содержит все представления для класса контроллера HomeController.
Папка Shared
Внутри папки Views имеется специальная папка по имени Shared, которая доступна всем контроллерам и их методам действий. Если представление не удалось найти в папке с именем контроллера, тогда поиск представления продолжается в папке Shared.
Папка wwwroot (нововведение в ASP.NET Core)
Улучшением по сравнению ASP.NET MVC стало создание особой папки по имени wwwroot для веб-приложений ASP.NET Core. В ASP.NET MVC файлы JavaScript, изображений, CSS и другое содержимое клиентской стороны смешивалось в остальных папках. В ASP.NET Core все файлы клиентской стороны содержатся в папке wwwroot. Такое отделение скомпилированных файлов от файлов клиентской стороны значительно проясняет структуру проекта при работе с ASP.NET Core.
Контроллеры и действия
Как и в ASP.NET MVC и ASP.NET Web API, контроллеры и методы действий являются основополагающими компонентами приложения ASP.NET Core MVC или API.
Класс Controller
Ранее уже упоминалось, что инфраструктура ASP.NET Core унифицировала ASP.NET MVC5 и ASP.NETWeb API. Такая унификация также привела к объединению базовых классов Controller.ApiController и AsyncController из MVC5 и Web API 2.2 в один новый класс Controller, который имеет собственный базовый класс по имени ControllerBase. Контроллеры веб-приложений ASP.NET Core наследуются от класса Controller, тогда как контроллеры служб ASP.NET — от класса ControllerBase (рассматривается следующим). Класс Controller предлагает множество вспомогательных методов для веб-приложений, наиболее часто используемые из которых перечислены в табл. 29.1.
Класс ControllerBase
Класс ControllerBase обеспечивает основную функциональность для веб-приложений и служб ASP.NET Core, и вдобавок предлагает вспомогательные методы для возвращения кодов состояния HTTP. В табл. 29.2 описана основная функциональность класса ControllerBase, а в табл. 29.3 перечислены некоторые вспомогательные методы для возвращения кодов состояния HTTP.
Действия
Действия — это методы в контроллере, которые возвращают экземпляр типа IActionResult (или Task<IActionResult> для асинхронных операций) либо класса, реализующего IActionResult, такого как ActionResult или ViewResult. Действия будут подробно рассматриваться в последующих главах.
Привязка моделей
Привязка моделей представляет собой процесс, в рамках которого инфраструктура ASP.NET Core использует пары "имя-значение", отправленные НТТР-методом POST, для присваивания значений свойствам моделей. Для привязки к ссылочному типу пары "имя-значение" берутся из значений формы или тела запроса, ссылочные типы обязаны иметь открытый стандартный конструктор, а свойства, участвующие в привязке, должны быть открытыми и допускать запись. При присваивании значений везде, где это применимо, используются неявные преобразования типов (вроде установки значения свойства string в значение int). Если преобразование типа терпит неудачу, тогда такое свойство помечается как имеющее ошибку Прежде чем начать подробное обсуждение привязки, важно понять предназначение словаря ModelState и его роль в процессе привязки (а также проверки достоверности).
Словарь ModelState
Словарь ModelState содержит записи для всех привязываемых свойств и запись для самой модели. Если во время привязки возникает ошибка, то механизм привязки добавляет ее к записи словаря для свойства и устанавливает ModelState.IsValid в false. Если всем нужным свойствам были успешно присвоены значения, тогда механизм привязки устанавливает ModelState.IsValid в true.
На заметку! Проверка достоверности модели, которая тоже устанавливает записи словаря ModelState, происходит после привязки модели. Как неявная, так и явная привязка модели автоматически вызывает проверку достоверности для модели. Проверка достоверности рассматривается в следующем разделе.
Добавление специальных ошибок в словарь ModelState
В дополнение к свойствам и ошибкам, добавляемым механизмом привязки, в словарь ModelState можно добавлять специальные ошибки. Ошибки могут добавляться на уровне свойств или целой модели. Чтобы добавить специфическую ошибку для свойства (например, свойства PetName сущности Car), применяйте такой код:
ModelState.AddModelError("PetName","Name is required");
Чтобы добавить ошибку для целой модели, указывайте в качестве имени свойства string.Empty:
ModelState.AddModelError(string.Empty, $"Unable to create record: {ex.Message}");
Неявная привязка моделей
Неявная привязка моделей происходит, когда привязываемая модель является параметром для метода действия. Для сложных типов она использует рефлексию и рекурсию, чтобы сопоставить имена