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

Троелсен Эндрю

Приложения API должны иметь политики, которые разрешают или запрещают взаимодействовать с ними клиентам, обращающимся из другого сервера. Такие типы запросов называются запросами между источниками (cross-origin requests — CORS). Хотя в этом нет необходимости при работе локально на своей машине для всего мира ASP.NET Core, поддержка CORS нужна фреймворкам JavaScript, которые желают взаимодействовать с вашим приложением API, даже когда они все вместе функционируют локально.

На заметку!

Дополнительные сведения о поддержке CORS ищите в документации по ссылке

https://docs.microsoft.com/ru-ru/aspnet/core/security/cors

.

Создание политики CORS

Инфраструктура ASP.NET Core располагает развитой поддержкой конфигурирования CORS, включая методы для разрешения/запрещения заголовков, методов, источников, учетных данных и многого другого. В этом примере все будет оставлено максимально открытым.

Конфигурирование начинается с создания политики CORS и добавления ее в коллекцию служб. Политика имеет имя (оно будет использоваться в методе

Configure

), за которым следуют правила. Далее будет сознана политика по имени

AllowAll

, разрешающая все. Добавьте в метод

ConfigureServices

класса

Startup

следующий код:

services.AddCors(options =>

{

options.AddPolicy("AllowAll", builder =>

{

builder

.AllowAnyHeader

.AllowAnyMethod

.AllowAnyOrigin;

});

});

Добавление политики CORS в конвейер обработки HTTP

Наконец, политику CORS необходимо добавить в конвейер обработки HTTP. Поместите между вызовами

арр. UseRouting

и

арр.UseEndpoints

в методе

Configure

класса

Startup

показанную ниже строку (выделенную полужирным):

public void Configure(

IApplicationBuilder app,

IWebHostEnvironment env,

ApplicationDbContext context)

{

...

// Включить маршрутизацию.

app.UseRouting;

// Добавить политику CORS.

app.UseCors("AllowAll");

// Включить проверки авторизации.

app.UseAuthorization;

...

}

Резюме

В

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

ApiController

и его влияние на контроллеры API. Затем вы обновили общую реализацию Swashbuckle, чтобы включить XML-документацию приложения и информацию из атрибутов методов действий.

Далее был построен базовый контроллер, содержащий большинство функциональности приложения. После этого в проект были добавлены производные контроллеры, специфичные для сущностей. В заключение был добавлен фильтр исключений уровня приложения и поддержка запросов между источниками.

В следующей главе вы завершите построение веб-приложения ASP.NET Core, т.е.

AutoLot.Mvc

.

Глава 31

Создание приложений MVC с помощью ASP.NET Core

В главе 29 была заложена основа ASP.NET Core, а в главе 30 вы построили службу REST. В этой главе вы будете создавать веб-приложение с использованием паттерна МУС. Все начинается с помещения "V" обратно в "МУС".

На заметку! Исходный код, рассматриваемый в этой главе, находится в папке

Chapter_31

внутри хранилища GitHub для настоящей книги. Вы также можете продолжить работу с решением, начатым в главе 29 и обновленным в главе 30.

Введение в представления ASP.NET Core

При построении служб ASP.NET Core были задействованы только части "М " (модели) и "С" (контроллеры ) паттерна МУС. Пользовательский интерфейс создается с применением части "V", т.е. представлений паттерна МУС. Представления строятся с использованием кода HTML, JavaScript, CSS и Razor. Они необязательно имеют страницу базовой компоновки и визуализируются из метода действия контроллера или компонента представления. Если вы имели дело с классической инфраструктурой ASP.NET МУС, то все должно выглядеть знакомым.

Экземпляры класса ViewResult и методы действий

Как кратко упоминалось в главе 29, объекты результатов

ViewResult

и

PartialView

являются экземплярами класса

ActionResult

, которые возвращаются из методов действий с применением вспомогательных методов класса

Controller

. Класс

PartialViewResult

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

ViewResult

обычно визуализируется в сочетании со страницей компоновки.