Точно так же, как Entity Framework Core является полной переработкой Entity Framework 6, инфраструктура ASP.NET Core — это переработка популярной инфраструктуры ASP.NET Framework. Переписывание ASP.NET было нелегкой, но необходимой задачей, преследующей цель устранить зависимости от System.Web. Избавление от указанной зависимости позволило запускать приложения ASP.NET под управлением операционных систем, отличающихся от Windows, и веб-серверов помимо Internet Information Services (IIS), включая размещаемые самостоятельно. В итоге у приложений ASP.NET Core появилась возможность использовать межплатформенный, легковесный и быстрый веб-сервер с открытым кодом под названием Kestrel, который предлагает унифицированный подход к разработке для всех платформ.

На заметку! Изначально продукт Kestrel был основан на LibUV, но после выпуска ASP.NET Core 2.1 он базируется на управляемых сокетах.

Подобно EF Core инфраструктура ASP.NET Core разрабатывается в виде проекта с полностью открытым кодом на GitHub (https://github.com/aspnet). Она также спроектирована как модульная система пакетов NuGet. Разработчики устанавливают только те функциональные средства, которые нужны для конкретного приложения, сводя к минимуму пространство памяти приложения, сокращая накладные расходы и снижая риски в плане безопасности. В число дополнительных улучшений входят упрощенный запуск, встроенное внедрение зависимостей, более чистая система конфигурирования и подключаемое промежуточное программное обеспечение (ПО).

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

В оставшихся главах этой части вы увидите, что в 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 сократили объем необходимой конфигурации за счет введения ряда соглашений. В случае соблюдения таких соглашений уменьшается объем ручного (или шаблонного) конфигурирования, но при этом разработчики обязаны знать соглашения, чтобы использовать их в своих интересах. Двумя главными видами соглашений являются соглашения об именовании и структура каталогов.

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