Язык программирования C#9 и платформа .NET5 - Троелсен Эндрю - Страница 576

Одна инфраструктура, много сценариев использования

В оставшихся главах этой части вы увидите, что в ASP.NET Core внесено множество изменений и усовершенствований. Помимо межплатформенных возможностей еще одним значительным изменением следует считать унификацию инфраструктур для создания веб- приложений. В рамках ASP.NET Core инфраструктуры ASP.NET MVC, ASP.NET Web API и Razor Pages объединены в единую инфраструктуру для разработки. Разработка веб-приложений и служб с применением полной инфраструктуры .NET Framework предоставляла несколько вариантов, включая Web Forms, MVC, Web API, Windows Communication Foundation (WCF) и WebMatrix. Все они имели положительные и отрицательные стороны; одни были тесно связаны между собой, а другие сильно отличались друг от друга. Наличие стольких доступных вариантов означало, что разработчики обязаны были знать каждый из них для выбора того, который подходит для имеющейся задачи, или просто отдавать предпочтение какому-то одному и положиться на удачу.

С помощью ASP.NET Core вы можете строить приложения, которые используют Razor Pages, паттерн MVC, службы REST и одностраничные приложения, где применяются библиотеки JavaScript вроде Angular либо React. Хотя визуализация пользовательского интерфейса зависит от выбора между MVC, Razor Pages или библиотеками JavaScript, лежащая в основе среда разработки остается той же самой. Двумя прежними вариантами, которые не были перенесены в ASP.NET Core, оказались Web Forms и WCF.

На заметку! Поскольку все обособленные инфраструктуры объединены вместе под одной крышей, прежние названия ASP.NET MVC и ASP.NET Web API официально были изъяты из употребления. Для простоты в этой книге веб-приложения ASP . NET Core, использующие паттерн "модель-представление-контроллер", упоминаются как MVC, а REST-службы ASP.NET - как Web API.

Функциональные средства ASP.NET Core из MVC/Web API

 Многие проектные цели и функции, которые побудили разработчиков применять ASP.NET MVC и ASP.NET Web API, по-прежнему поддерживаются в ASP.NET Core (и были улучшены).

Ниже перечислены некоторые из них (но далеко не все):

• соглашения по конфигурации (convention over configuration; или соглашение над конфигурацией, если делать акцент на преимуществе соглашения перед конфигурацией);

• контроллеры и действия;

• привязка моделей;

• проверка достоверности моделей;

• маршрутизация;

• фильтры;

• компоновки и представления Razor.

Они рассматриваются в последующих разделах за исключением компоновок и представлений Razor, которые будут раскрыты в главе 31.

Соглашения по конфигурации

ASP.NET MVC и ASP .NET Web API сократили объем необходимой конфигурации за счет введения ряда соглашений. В случае соблюдения таких соглашений уменьшается объем ручного (или шаблонного) конфигурирования, но при этом разработчики обязаны знать соглашения, чтобы использовать их в своих интересах. Двумя главными видами соглашений являются соглашения об именовании и структура каталогов.

Соглашения об именовании

В ASP.NET Core существует множество соглашений об именовании, предназначенных для приложений MVC и API. Например, контроллеры обычно содержат суффикс

в своих именах (скажем, ) и вдобавок порождены от класса (или ). При доступе через маршрутизацию суффикс отбрасывается. При поиске представлений контроллера отправной точкой поиска будет имя контроллера без суффикса. Такое соглашение об отбрасывании суффикса встречается повсюду в ASP.NET Core. В последующих главах вы встретите немало примеров.

(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})

Еще одно соглашение об именовании применяется относительно местоположения и выбора представлений. По умолчанию метод действия (в приложении MVC) будет визуализировать представление с таким же именем, как у метода. Шаблоны редактирования и отображения именуются в соответствии с классом, который они визуализируют в представлении. Описанное стандартное поведение может быть изменено, если того требует ваше приложение. Все это будет дополнительно исследоваться при построении приложения

.

Структура каталогов

Существует несколько соглашений о папках, которые вы должны понимать, чтобы успешно создавать веб-приложения и службы ASP.NET Core.

Папка Controllers

По соглашению папка

является тем местом, где реализации ASP.NET Core MVC и API (а также механизм маршрутизации) ожидают обнаружить контроллеры для вашего приложения.

Папка Views

В папке

хранятся представления для приложения. Каждый контроллер получает внутри главной папки собственную папку с таким же именем, как у контроллера (исключая суффикс ). По умолчанию методы действий будут визуализировать представления из папки своего контроллера. Например, папка Views/Home содержит все представления для класса контроллера .

Папка Shared

Внутри папки

имеется специальная папка по имени , которая доступна всем контроллерам и их методам действий. Если представление не удалось найти в папке с именем контроллера, тогда поиск представления продолжается в папке .

Папка wwwroot (нововведение в ASP.NET Core)

Улучшением по сравнению ASP.NET MVC стало создание особой папки по имени

для веб-приложений 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. Такая унификация также привела к объединению базовых классов

и из MVC5 и Web API 2.2 в один новый класс , который имеет собственный базовый класс по имени . Контроллеры веб-приложений ASP.NET Core наследуются от класса , тогда как контроллеры служб ASP.NET — от класса (рассматривается следующим). Класс предлагает множество вспомогательных методов для веб-приложений, наиболее часто используемые из которых перечислены в табл. 29.1.