Введение

Аннотация. Разработка современных веб-приложений требует выбора надёжного и производительного фреймворка, который позволяет создавать масштабируемые и защищённые системы. ASP.NET Core — это кроссплатформенный фреймворк с открытым исходным кодом, который полностью переосмысливает подход к созданию веб-приложений на платформе .NET, предлагая унифицированную модель для построения MVC-приложений, Razor Pages, Web API и компонентов реального времени. Данный курс решает задачу быстрого и структурированного входа в технологию, охватывая фундаментальные принципы, такие как внедрение зависимостей, конфигурация, работа с базами данных через Entity Framework Core, безопасность на основе JWT и развёртывание в контейнерах Docker. Материал ориентирован на разработчиков, желающих перейти от классической .NET Framework к современным решениям, и на тех, кто ищет практические рецепты для создания высоконагруженных веб-систем.

Цель курса. После прохождения курса вы сможете самостоятельно проектировать, разрабатывать и разворачивать полнофункциональные веб-приложения на ASP.NET Core, используя все ключевые компоненты фреймворка, включая MVC, Razor Pages, Web API, SignalR, JWT-аутентификацию и модульное тестирование, а также контейнеризировать их с помощью Docker.

Для кого этот курс.

Этот курс предназначен для практикующих C#-разработчиков, которые хотят освоить современный стек веб-разработки на .NET. Он будет полезен как опытным специалистам, переходящим с .NET Framework, так и начинающим разработчикам, знакомым с основами C#, но желающим систематизировать знания о построении веб-приложений. Backend-инженеры найдут здесь глубокие инструкции по созданию Web API и защите эндпоинтов, а full-stack разработчики — по интеграции с фронтенд-фреймворками через SignalR и REST.

Курс не подходит тем, кто не знаком с основами объектно-ориентированного программирования на C#, и тем, кто ищет руководство по дизайну пользовательских интерфейсов (UI/UX). Данный материал сосредоточен именно на Hard skill — технической реализации серверной логики.

Модуль 1. Основы и архитектура ASP.NET Core

Что такое ASP.NET Core и эволюция платформы. ASP.NET Core — это полная перезагрузка классического ASP.NET, направленная на модульность, высокую производительность и кроссплатформенность. В отличие от .NET Framework, который привязан к Windows, ASP.NET Core работает на Windows, Linux и macOS. Ключевые отличия: унифицированный стек (MVC, Web API, Razor Pages в одном фреймворке), встроенный контейнер внедрения зависимостей и новый высокопроизводительный веб-сервер Kestrel. Выбор версии зависит от потребностей: для долгосрочной поддержки выбирайте LTS-версии (например, .NET 8.0), для использования новейших языковых конструкций — текущие релизы. Понимание этой эволюции позволяет правильно планировать миграцию проектов и использовать современные паттерны. Не рекомендуется создавать новые проекты на устаревших версиях без долгосрочной поддержки.

Структура проекта и файл Program.cs. Современный шаблон проекта ASP.NET Core использует модель «минимального API» и упрощённый файл Program.cs, где происходит настройка хоста и приложения. В этом файле выделяются два основных этапа: построение веб-приложения через WebApplication.CreateBuilder(args) и его конфигурация через app. Здесь регистрируются сервисы (через builder.Services) и строится конвейер обработки запросов (через app.Use...). Важно понимать, что метод builder.Build() финализирует конфигурацию, и после него изменения в регистрации сервисов невозможны. Например, добавление поддержки MVC выглядит как builder.Services.AddControllersWithViews(), а для Razor Pages — builder.Services.AddRazorPages(). Структура папок включает wwwroot для статики, Pages для Razor, Controllers для MVC и Models для моделей данных. Это стандарт, который обеспечивает единообразие проектов.

Конфигурация приложения и appsettings.json. Система конфигурации в ASP.NET Core иерархична и гибка, поддерживая JSON, XML, переменные среды и командную строку. Файл appsettings.json служит основным хранилищем настроек, а appsettings.Development.json переопределяет параметры для локальной разработки (например, строки подключения к локальной БД). Строки подключения к чувствительным данным, таким как пароли, не следует хранить в коде; для разработки используется «Secret Manager», а в продакшене — переменные окружения или Azure Key Vault. Доступ к конфигурации осуществляется через свойство IConfiguration, которое инжектируется в конструкторы. Рекомендуется использовать паттерн «Options» привязки для строго типизированного доступа к секциям через services.Configure(configuration.GetSection("MySection")). Это улучшает читаемость и упрощает модульное тестирование.

Модуль 2. HTTP Pipeline и Middleware

Конвейер обработки запросов Middleware. Обработка HTTP-запросов в ASP.NET Core реализована как цепочка компонентов Middleware. Каждый компонент имеет доступ к объекту HttpContext, может обработать запрос, передать его следующему компоненту или завершить выполнение, вернув ответ. Это похоже на конвейерные функции, где порядок добавления через app.Use... критичен: компоненты выполняются в том порядке, в котором они зарегистрированы. Например, app.UseHttpsRedirection() должен выполняться до app.UseRouting(), чтобы перенаправление на HTTPS произошло до выбора эндпоинта. Встроенные компоненты, такие как аутентификация (UseAuthentication) и авторизация (UseAuthorization), обычно располагаются между маршрутизацией и конечными точками. Эта архитектура обеспечивает высокую гибкость: разработчик может встраивать собственные логи для логирования, обработки ошибок, сжатия или изменения заголовков.

Встроенные Middleware и настройка Pipeline. ASP.NET Core предоставляет набор стандартных Middleware для решения типовых задач. UseDeveloperExceptionPage отображает детальную страницу ошибок для разработки, которая должна быть отключена в продакшене в пользу UseExceptionHandler("/Error"). UseHsts добавляет заголовок HSTS (HTTP Strict Transport Security), требующий от браузеров использовать HTTPS. UseStaticFiles позволяет обслуживать статические файлы из wwwroot, что необходимо для CSS, JS и изображений. Важно понимать, что UseRouting() включает систему маршрутизации, а UseEndpoints(...) определяет, как обрабатывать сопоставленные запросы (например, маппинг контроллеров или Razor Pages). Правильная комбинация этих методов создаёт высокопроизводительный и безопасный конвейер, где каждое звено выполняет строго свою функцию, не смешивая логику.

Создание пользовательского Middleware. Создание собственного Middleware часто необходимо для кросс-функциональных задач, таких как глобальное логирование, обработка токенов или проверка IP-адресов. Существует два основных способа: написание класса с методом InvokeAsync и регистрация inline-делегата через app.Use. Класс должен принимать параметр RequestDelegate next и иметь метод async Task InvokeAsync(HttpContext context). Для передачи сервисов в Middleware используется внедрение зависимостей через конструктор (singleton) или через параметры Invoke (scoped). Пример: логирование времени выполнения запроса — до вызова next(context) фиксируем время старта, после — вычисляем разницу. Важно избегать тяжёлых операций в конструкторе и всегда вызывать next для продолжения конвейера, если только вы сознательно не обрываете выполнение, например, при 404 ошибке.

Прокси и Reverse Proxy с YARP. YARP (Yet Another Reverse Proxy) — это библиотека от Microsoft для создания reverse proxy серверов на базе ASP.NET Core. YARP интегрируется с конвейером Middleware, позволяя обрабатывать запросы и перенаправлять их во внутренние сервисы. Настройка выполняется через AddReverseProxy() и LoadFromConfig, где маршруты и кластеры (группы целевых серверов) описываются в конфигурации. MapReverseProxy создаёт эндпоинты для проксирования. Внутри pipeline можно добавлять собственные middleware для фильтрации или модификации запросов до их отправки в бэкенд. Это мощный инструмент для создания API Gateways, балансировки нагрузки и реализации паттерна «Gateway Aggregation». Важно помнить, что middleware, добавленные внутри MapReverseProxy, имеют доступ к данным о кластере через IReverseProxyFeature, что позволяет динамически выбирать целевые хосты.

Модуль 3. Маршрутизация, MVC и Razor Pages

Маршрутизация и атрибуты маршрутов. Маршрутизация определяет, как URL сопоставляются с действиями (Actions) контроллеров. В ASP.NET Core доминирует атрибутивная маршрутизация, которая даёт полный контроль над шаблонами URL прямо в коде контроллера через атрибуты [Route], [HttpGet], [HttpPost] и другие. Например, [Route("api/[controller]")] задаёт базовый путь, а [HttpGet("{id}")] добавляет параметр. Атрибутивная маршрутизация предпочтительнее конвенциональной, так как она явно связывает URL с методом, упрощает понимание структуры API и поддерживает ограничения (constraints), например {id:int} гарантирует, что параметр является целым числом, избегая лишней обработки ошибок в коде. При использовании [ApiController] атрибут становится обязательным, что улучшает самодокументируемость API.

Создание контроллеров и Web API. Контроллеры в ASP.NET Core обрабатывают входящие HTTP-запросы. Для создания RESTful API контроллер наследуется от ControllerBase (без поддержки представлений) и помечается атрибутом [ApiController], который включает автоматическую валидацию моделей и привязку источника данных. Каждый публичный метод обычно помечается HTTP-глаголом: [HttpGet], [HttpPost], [HttpPut], [HttpDelete]. Атрибут [Route] может быть применён на уровне контроллера и метода. Важно использовать специализированные методы результата из ControllerBase, такие как Ok(), NotFound(), BadRequest() и CreatedAtAction(), которые возвращают соответствующие HTTP-статусы и стандартизируют ответы. Преимуществом этого подхода является декларативность и возможность автоматической генерации документации OpenAPI (Swagger).

Razor Pages и их отличие от MVC. Razor Pages — это подход, упрощающий создание страниц, ориентированных на пользовательский интерфейс, за счёт устранения слоя контроллеров. В отличие от MVC, где логика разбросана по контроллерам и моделям, каждая Razor Page является самодостаточной единицей: файл .cshtml содержит HTML и серверный код на Razor, а файл .cshtml.cs выступает в роли «обработчика» (PageModel), содержащего логику страницы. Эта модель идеально подходит для форм, приложений с интенсивным UI и CRUD-операций. Маршрутизация работает на основе имени файла (/Index, /Privacy), но может быть переопределена директивой @page. Для чайников и задач, где контроллеры кажутся избыточными, Razor Pages предоставляют более прямую и интуитивную структуру, уменьшая количество шаблонного кода.

Фильтры в ASP.NET Core. Фильтры позволяют выполнять код до или после определённых этапов выполнения запроса, обеспечивая сквозную обработку, такую как кеширование, логирование и обработка исключений. Существует несколько типов: Авторизации (выполняются до всех остальных), Ресурса (для кеширования и работы до Model Binding), Действия (Action Filters) — обрамляют выполнение метода, и Исключения (для глобальной обработки ошибок). Фильтры могут быть реализованы как атрибуты (применяются к конкретному контроллеру или методу) или глобальные (применяются ко всем запросам). Например, ServiceFilterAttribute позволяет привязать фильтр, зарегистрированный в DI-контейнере, что упрощает внедрение зависимостей. Предпочтительным способом глобальной обработки ошибок является Middleware, а фильтры лучше использовать для логики, специфичной для конкретных действий, например, валидации входных данных или логирования времени выполнения метода.

Модуль 4. Внедрение зависимостей (DI) и работа с данными

Контейнер внедрения зависимостей. Внедрение зависимостей (Dependency Injection, DI) — встроенный механизм в ASP.NET Core, реализующий паттерн Inversion of Control (IoC). Контейнер управляет временем жизни объектов (сервисов), избавляя разработчика от их ручного создания и уничтожения. Регистрация сервисов происходит в Program.cs через builder.Services с указанием трёх основных времен жизни: Singleton (один экземпляр на всё приложение, создаётся при первом запросе или регистрации), Scoped (один экземпляр на один HTTP-запрос) и Transient (новый экземпляр при каждом запросе сервиса). Критически важно использовать Scoped сервисы (например, DbContext Entity Framework) внутри Scoped или Transient контекстов, избегая их внедрения в Singleton, чтобы не вызвать утечки памяти или проблемы с параллелизмом. Контейнер автоматически разрешает зависимости конструктора, что способствует созданию слабосвязанного и тестируемого кода.

Жизненные циклы сервисов и управление памятью. Понимание времен жизни служб критично для производительности и стабильности. Transient сервисы создаются каждый раз при их запросе; они идеальны для легковесных, не поддерживающих состояние компонентов. Scoped сервисы — стандартный выбор для веб-приложений, когда необходимо сохранять состояние в рамках одного запроса (например, доступ к БД). Singleton — используется для кешей, настроек и сервисов, работающих с общими ресурсами. Ошибкой является захват IDisposable Scoped сервиса в Singleton: контейнер удерживает его до завершения приложения, что приводит к утечкам памяти и непредсказуемому поведению. Для разрешения Scoped сервисов за пределами HTTP-запроса (например, в фоновых задачах или при старте приложения) используется создание отдельного Scope через app.Services.CreateScope(), что гарантирует корректное освобождение ресурсов. Это особенно актуально при использовании Entity Framework Core.

Entity Framework Core как основной ORM. Entity Framework Core (EF Core) — это современный объектно-ориентированный маппер (ORM) для .NET, упрощающий взаимодействие с базами данных. Он позволяет работать с реляционными данными через объекты C#, используя мощные LINQ-запросы, которые транслируются в SQL-запросы. Поддерживаются различные СУБД: SQL Server, PostgreSQL, MySQL, SQLite и Azure Cosmos DB. Основные подходы к разработке: Code First (создание БД на основе классов моделей) и Database First (генерация классов из существующей БД). Для контекста данных (DbContext) жизненный цикл Scoped является стандартом, что гарантирует, что каждый HTTP-запрос получает свой экземпляр контекста, позволяя безопасно выполнять транзакции и отслеживать изменения. Рекомендуется использовать асинхронные методы (например, ToListAsync) для предотвращения блокировок потоков и повышения пропускной способности приложения.

Миграции и управление схемой данных. Миграции EF Core — это способ синхронизации структуры базы данных с моделями приложения. Каждый раз при изменении модели создаётся новая миграция через команду Add-Migration Name (или dotnet ef migrations add Name), которая содержит методы Up и Down для применения и отката изменений. Затем миграции применяются к БД с помощью Update-Database. Это гарантирует, что схема данных развивается вместе с кодом, сохраняя историю изменений в папке Migrations. В продакшене часто используют автоматическое применение миграций при старте приложения через context.Database.MigrateAsync(), но это сопряжено с рисками, поэтому рекомендуется использовать отдельные скрипты миграции в CI/CD пайплайнах. Важно никогда не удалять существующие миграции без крайней необходимости, чтобы сохранить целостность истории изменений.

Модуль 5. Безопасность: Identity, JWT и Авторизация

ASP.NET Core Identity для управления пользователями. ASP.NET Core Identity — это полноценная система управления пользователями, поддерживающая регистрацию, вход, сброс пароля, роли и двухфакторную аутентификацию (2FA). Она плотно интегрируется с Entity Framework Core, предоставляя стандартную схему базы данных для хранения логинов и профилей. Для одностраничных приложений (SPA) доступна поддержка IdentityServer (Duende IdentityServer) через AddIdentityServerJwt, что позволяет выдавать токены JWT для аутентификации с фронтенда. С версии .NET 8 появились встроенные API-эндпоинты для Identity, упрощающие логику регистрации и логина без необходимости написания контроллеров. Важно настраивать политики паролей, блокировки и подтверждения email для обеспечения минимального уровня безопасности из коробки. Рекомендуется использовать Microsoft Entra ID (Azure AD) для корпоративных приложений, но Identity остаётся стандартом для локальных и облачных решений.

Настройка JWT Bearer Authentication. JWT (JSON Web Token) — это стандарт для передачи аутентификационной информации между клиентом и сервером. В ASP.NET Core настройка JWT-аутентификации выполняется через метод AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(...). В параметрах конфигурации необходимо указать Authority (адрес провайдера токенов), Audience (аудитория, для которой предназначен токен) и задать параметры валидации (TokenValidationParameters), включая проверку подписи (IssuerSigningKey), срока действия (ValidateLifetime) и издателя. Для локальной разработки часто используются асимметричные ключи или подпись с использованием симметричного ключа (Symmetric Security Key). Безопасный подход требует хранения секретных ключей в Key Vault или переменных окружения. Важно установить свойство ValidateIssuerSigningKey = true и никогда не отключать проверку HTTPS для эндпоинтов токенов в продакшене.

Авторизация: политики, роли и требования. В отличие от аутентификации, которая проверяет личность, авторизация определяет, что пользователю разрешено делать. В ASP.NET Core доступна гибкая система на основе политик (Policies). Простая проверка ролей (например, [Authorize(Roles = "Admin")]) подходит для базовых сценариев, но политики позволяют реализовать сложную логику через требования (IAuthorizationRequirement). Например, политика может проверять, достиг ли пользователь 18 лет или имеет ли он право на просмотр конкретного документа. Создание политики происходит через AddAuthorizationBuilder().AddPolicy("Over18", policy => policy.Requirements.Add(new AgeRequirement(18))). Затем политика применяется через [Authorize(Policy = "Over18")]. Это позволяет отделить бизнес-правила от контроллеров, делая код более чистым и тестируемым. Важно использовать [AllowAnonymous] для открытых эндпоинтов внутри защищённых контроллеров.

Защита от уязвимостей (Security Best Practices). Разработка безопасных приложений требует предотвращения распространённых атак. ASP.NET Core предоставляет встроенную защиту от CSRF (Cross-Site Request Forgery) через антифорговые токены в формах, от XSS (Cross-Site Scripting) через автоматическое кодирование данных в Razor и от атак перенаправления. Для защиты данных в покое и при передаче необходимо использовать HTTPS (настройка UseHttpsRedirection и UseHsts). Никогда не храните пароли или ключи в коде или файлах конфигурации, используйте Key Vault или переменные окружения. Для аутентификации всегда предпочитайте современные протоколы, такие как OpenID Connect или OAuth 2.0, избегая устаревшего Resource Owner Password Credentials (ROPC), который раскрывает пароль клиенту. Регулярно обновляйте пакеты NuGet для закрытия известных уязвимостей и используйте инструменты сканирования безопасности в CI/CD.

Модуль 6. Реальное время и коммуникации: SignalR

Введение в SignalR и веб-сокеты. SignalR — это библиотека для ASP.NET Core, которая упрощает добавление функциональности реального времени в веб-приложения. Она автоматически выбирает оптимальный транспорт (WebSockets, Server-Sent Events или Long Polling), обеспечивая постоянное соединение между клиентом и сервером. Это идеальное решение для чатов, игр, онлайн-табло и потоковых уведомлений. В отличие от REST API, где клиент инициирует соединение, SignalR позволяет серверу отправлять данные клиентам асинхронно. Настройка включает добавление builder.Services.AddSignalR() в DI и маппинг хабов через app.MapHub("/chatHub"). Поддержка клиентов реализована для JavaScript, .NET, Java и других платформ.

Создание и настройка Хаба (Hub). Хаб в SignalR — это класс, наследующий от Hub, который обрабатывает входящие сообщения от клиентов и отправляет сообщения обратно. Методы хаба вызываются клиентами (например, SendMessage), а отправка сообщений клиентам выполняется через свойство Clients. Методы являются асинхронными (async Task) для обеспечения масштабируемости. Для передачи данных используются строго типизированные объекты. В хабе можно управлять группами (Groups.AddToGroupAsync), позволяя отправлять сообщения подмножеству клиентов. Для строгой типизации можно создать интерфейс клиента (например, IChatClient) и использовать Hub, чтобы методы вызова клиента были типобезопасными. Это снижает вероятность ошибок при рефакторинге.

Интеграция JavaScript клиента SignalR. Клиентская библиотека SignalR для JavaScript предоставляется через пакет NPM (@microsoft/signalr). Для её установки часто используется LibMan (Library Manager) или менеджер пакетов. В браузерном коде создаётся экземпляр HubConnectionBuilder, настраивается URL хаба и применяется метод withAutomaticReconnect() для автоматического переподключения при обрыве связи. Клиент подписывается на события через connection.on("ReceiveMessage", callback) и вызывает методы хаба через connection.invoke("SendMessage", data). Рекомендуется использовать start() и обрабатывать ошибки в catch, так как подключение к хабу может быть асинхронным и потенциально неудачным. Для больших приложений стоит рассмотреть использование контрактов на основе интерфейсов, чтобы синхронизировать клиентские и серверные события, повышая читаемость и уменьшая количество «магических строк».

Модуль 7. Развёртывание и DevOps

Публикация и подготовка к деплою. Процесс публикации ASP.NET Core приложения начинается с команды dotnet publish -c Release -o ./publish, которая собирает приложение в Release-конфигурации и копирует все необходимые файлы (библиотеки, статику, конфигурации) в папку publish. Это единственная папка, необходимая для работы приложения, что упрощает её перенос на сервер. В зависимости от настроек профиля публикации (.pubxml) можно настроить исключение или включение дополнительных файлов. Результат публикации зависит от типа развёртывания: Framework-dependent (зависит от установленного на хосте .NET Runtime) — даёт меньший размер, или Self-contained (включает свою копию .NET) — даёт независимость от версии рантайма на сервере. Для Linux деплоя обычно используется Self-contained или кросс-платформенный Framework-dependent с установленным ASP.NET Core Runtime.

Настройка сервера и Kestrel. Kestrel — это кроссплатформенный веб-сервер, интегрированный в ASP.NET Core. Для запуска в продакшене стандартной практикой является использование Reverse Proxy (Nginx или IIS), который принимает запросы из интернета и перенаправляет их в Kestrel. Это добавляет уровень защиты, позволяет балансировать нагрузку и отдавать статические файлы. Kestrel настраивается через файл appsettings.json или переменные окружения: можно задать порты (например, ASPNETCORE_URLS="http://*:5000"), лимиты на размер запросов и таймауты. Для высоконагруженных систем важно правильно настроить пул потоков и количество одновременных соединений. Запуск приложения производится через dotnet .dll, либо как служба (Windows Service) или демон (systemd на Linux).

Контейнеризация с помощью Docker. Docker позволяет упаковать приложение со всеми зависимостями в изолированный контейнер, гарантируя одинаковую работу в любой среде. Официальный образ Microsoft mcr.microsoft.com/dotnet/aspnet используется как базовый слой для запуска, а образ dotnet/sdk — для сборки. Многостадийная сборка (multi-stage build) в Dockerfile минимизирует итоговый размер: сначала приложение собирается в SDK-контейнере, затем артефакты копируются в чистый runtime-контейнер. Команды сборки и запуска контейнера: docker build -t myapp . и docker run -d -p 8080:80 --name myapp myapp. Переменные окружения для контейнера (например, строки подключения) передаются через флаг -e или файл .env. Использование контейнеров упрощает масштабирование через оркестраторы, такие как Kubernetes, и стандартизирует DevOps-практики.

Деплой на VPS с использованием Docker Compose. Развёртывание на VPS (Virtual Private Server) часто включает использование Docker Compose для управления многоконтейнерными приложениями (например, приложение + база данных + кеш). На сервере необходимо установить Docker и Docker Compose. После клонирования репозитория и настройки docker-compose.yml (где описаны сервисы, порты и зависимости), запуск производится командой docker-compose up -d. Критически важно настроить SSL-сертификаты (Let's Encrypt) через reverse-proxy контейнер (например, Traefik или Nginx), чтобы обеспечить безопасное соединение. Для автоматизации CI/CD можно настроить Webhook, который при пуше в репозиторий будет пересобирать образы и перезапускать контейнеры, что минимизирует время простоя. Рекомендуется использовать отдельные томы (volumes) для хранения логов и статики, чтобы они сохранялись при обновлении контейнера.

Модуль 8. Практические аспекты, Мониторинг и Лучшие практики

Логирование и мониторинг. Логирование является критической частью любого продакшен-приложения. В ASP.NET Core используется встроенная абстракция ILogger, которая поддерживает различные провайдеры: Console, Debug, EventLog, Application Insights (Azure) и популярные сторонние библиотеки (Serilog, NLog). Для структурированного логирования рекомендуется использовать Serilog, который позволяет записывать данные в JSON-формате в Elasticsearch или другие системы, упрощая поиск и анализ. Важно различать уровни логирования: Information для бизнес-событий, Warning для нештатных ситуаций и Error для исключений. Избегайте логирования чувствительных данных (паролей, токенов) в тексте сообщений. Интеграция с Application Insights или Prometheus позволяет мониторить производительность, количество запросов и время отклика, что критично для SLA.

Модульное тестирование и xUnit. Тестирование — основа надёжности. В ASP.NET Core часто используется xUnit в качестве фреймворка для модульного тестирования. Благодаря внедрению зависимостей, контроллеры и сервисы легко тестируются изолированно с использованием моков (Moq или NSubstitute). Для тестирования контроллеров проверяется, что метод возвращает правильный тип ответа (ActionResult) и правильный HTTP-статус. Для тестирования интеграции с БД часто используется In-Memory Database или отдельная тестовая БД с контейнером. Полезно писать интеграционные тесты для проверки всего конвейера Middleware с помощью TestServer и WebApplicationFactory, что позволяет эмулировать запросы и проверять ответы без запуска реального веб-сервера. Минимальный порог покрытия тестами для критических бизнес-логик должен быть не менее 80%.

Оптимизация производительности: кеширование и асинхронность. Производительность ASP.NET Core достигается за счёт грамотного использования асинхронности и кеширования. Используйте асинхронные методы (async/await) для всех операций I/O (запросы к БД, HTTP-вызовы, файловые операции) чтобы не блокировать пул потоков. Для кеширования данных используйте MemoryCache (In-Memory) для частых, редко изменяющихся данных (например, справочники), и Distributed Cache (Redis) для распределённого кеширования в кластерных средах. Кеширование ответов (Response Caching) позволяет серверу отдавать закешированные страницы, снижая нагрузку на обработку. Важно избегать «жестокого» обращения с DbContext: не храните его в Singleton, всегда отслеживайте изменения только тогда, когда они нужны, и используйте AsNoTracking для запросов только на чтение, что значительно увеличивает скорость выборки данных.

Обработка исключений и отказоустойчивость. Надёжное приложение должно корректно обрабатывать ошибки. Middleware для обработки исключений (app.UseExceptionHandler) — стандартный способ перехвата необработанных исключений и возврата стандартизированного JSON-ответа (например, для API) или страницы ошибки (для UI). Для более детальной логики внутри контроллеров используются фильтры исключений (IExceptionFilter). Важно отличать ошибки приложения (Business Logic Errors) от ошибок инфраструктуры (Timeout, DB connection). Для повторных попыток при неудачных операциях с БД или внешними сервисами используйте библиотеки вроде Polly (Retry, Circuit Breaker паттерны). Всегда логируйте исключения полностью (logger.LogError(ex, "Message")) с контекстом операции для облегчения диагностики. Продумайте стратегию Graceful Shutdown для корректного завершения приложения при обновлениях или остановке контейнера.

Анти-паттерны и частые ошибки. В разработке на ASP.NET Core есть несколько типичных ошибок: 1) Использование HttpContext вне контекста запроса (в фоновых сервисах) — приводит к NullReferenceException. 2) Игнорирование асинхронности: вызов .Result или .Wait() в синхронном методе вызывает дедлоки. 3) Регистрация Scoped-сервиса как Singleton — приводит к использованию одного экземпляра на все запросы, что ломает изоляцию данных. 4) Хранение чувствительных данных в appsettings.json — компрометирует безопасность. 5) Слишком тяжёлые конструкторы контроллеров — замедляют запуск приложения. 6) Отсутствие обработки OperationCanceledException — приводит к ошибкам при отмене запросов. Избегайте жёсткого связывания (tight coupling) бизнес-логики с инфраструктурными деталями, это облегчает поддержку. Старайтесь минимизировать количество кода в контроллерах, вынося логику в отдельные сервисы (Thin Controllers, Fat Services).

Модуль 9. Выбор UI-подхода: Razor Pages, MVC и Blazor

Сравнительный обзор UI-решений в ASP.NET Core. В ASP.NET Core существует несколько подходов к построению пользовательского интерфейса: классические MVC и Razor Pages, а также современный Blazor. Каждый из этих фреймворков входит в состав ASP.NET Core и предназначен для решения разных задач . Для новых проектов компания Microsoft рекомендует использовать Blazor как наиболее современное решение . Однако важно понимать сильные стороны каждого подхода, чтобы сделать осознанный выбор. MVC подходит для крупных приложений с чётким разделением ответственности и сложной логикой контроллеров. Razor Pages упрощает создание страниц, объединяя код и представление, что удобно для форм и CRUD-операций. Blazor предоставляет возможность писать интерактивный UI на C# вместо JavaScript, что является революционным шагом для .NET-разработчиков.

Razor Pages — концепция и преимущества. Razor Pages — это модель на основе страниц, которая упрощает организацию кода по сравнению с классическим MVC . Вместо контроллеров и отдельных представлений, каждый Razor Page представляет собой самодостаточную единицу: файл .cshtml для HTML-разметки и связанный файл .cshtml.cs с логикой обработки (PageModel) . Такой подход обеспечивает более тесную связь между UI и бизнес-логикой, что ускоряет разработку и упрощает поддержку маленьких и средних приложений. Преимущества Razor Pages включают быструю разработку, хорошую тестируемость и масштабируемость для крупных проектов . Этот подход особенно эффективен для приложений с интенсивным пользовательским интерфейсом, таких как административные панели, личные кабинеты и системы управления контентом.

Маршрутизация, обработчики и валидация в Razor Pages. Маршрутизация в Razor Pages определяется директивой @page в верхней части файла .cshtml . Например, @page "/customers/{id:int}" задаёт маршрут и ограничение, что параметр id должен быть целым числом, иначе будет возвращена ошибка 404 . Обработка запросов выполняется в методах OnGet, OnPost, OnPostDeleteAsync и т.д., которые автоматически связываются с HTTP-глаголами . Валидация данных реализуется с помощью атрибутов из пространства имён System.ComponentModel.DataAnnotations . Например, [Required], [StringLength(10)] и [RegularExpression(@\«^[A-Z]+[a-zA-Z]*$\»)] позволяют декларативно описывать правила проверки. Эти атрибуты обеспечивают как серверную, так и клиентскую валидацию (с помощью jQuery Validation), что повышает безопасность и удобство использования.

Введение в Blazor — полный стек на C#. Blazor — это современный фреймворк для создания интерактивных веб-UI с использованием C# вместо JavaScript . Он позволяет создавать многократно используемые компоненты, которые эффективно обновляются при изменении данных . Blazor поддерживает несколько моделей хостинга: серверную (Blazor Server), клиентскую на WebAssembly (Blazor WebAssembly) и гибридную (Blazor Hybrid) . Ключевые преимущества: использование одного языка (C#) для всего приложения, высокая производительность рендеринга за счёт алгоритма сравнения, возможность повторного использования кода на клиенте и сервере и интеграция с существующими MVC или Razor Pages приложениями . Это делает Blazor идеальным выбором для команд, которые хотят минимизировать использование JavaScript и использовать весь потенциал экосистемы .NET.

Совместное использование UI-подходов. Все компоненты UI в ASP.NET Core (MVC, Razor Pages и Blazor) спроектированы так, чтобы их можно было использовать вместе в рамках одного приложения . Razor-компоненты Blazor можно интегрировать в существующие представления MVC или Razor Pages . Это позволяет модернизировать устаревшие приложения, добавляя интерактивные элементы без полной переписки кода. Например, можно использовать Tag Helper для встраивания компонента в представление: . Преимущества такого подхода: предварительный рендеринг на сервере улучшает время загрузки, а интеграция компонентов добавляет интерактивности без необходимости перехода на SPA-архитектуру. Это мощный инструмент для постепенного обновления приложений.