ASP.NET Базовый Полный Курс Для Начинающих

• Курс для начинающих по созданию веб-приложений с использованием .NET Core и C#.  

• Автор курса, Хулио Казаль, имеет опыт создания облачных приложений.  

• Цель курса - научить создавать серверную часть веб-приложений, даже для новичков.  

• Проект: создание раздела каталога игр в магазине видеоигр.  

• Разработчики интерфейса уже создали веб-интерфейс.  

• Задача серверной части: поддержка данных игр в реляционной базе данных.  

• Создание REST API для управления данными игр.  

• Создание и отладка первого приложения .NET Core.  

• Основные концепции REST API и реализация конечных точек.  

• Использование объектов передачи данных и методов расширения.  

• Проверка входных данных и поддержка баз данных с Entity Framework Core.  

• Изучение системы конфигурации .NET Core.  

• Шаблон проектирования внедрения зависимостей.  

• Сопоставление сущностей с DTO и асинхронная модель программирования.  

• Интеграция REST API с интерфейсом для улучшения взаимодействия с пользователями.  

• Базовые знания C#, Java или аналогичного языка.  

• Основы веб-разработки и опыт работы с реляционными базами данных.  

• Необходимое программное обеспечение: .NET SDK и Visual Studio Code.  

• Установка .NET SDK и Visual Studio Code.  

• Настройка Visual Studio Code для работы с .NET Core.  

• Установка расширений для улучшения опыта программирования на C#.  

• DevKit предоставляет улучшения для VS Code, включая обозреватель решений и поддержку C#.  

• Установлен инструмент для установки .NET, который предоставляет .NET runtime и SDK.  

• Рекомендуется установить расширение Rest Client для взаимодействия с веб-API.  

• Установлено расширение SQLite для работы с базами данных.  

• Проверка установки .NET через терминал.  

• Использование команд dotnet version и dotnet info для получения информации о .NET SDK.  

• Создание веб-проекта через терминал с помощью команды dotnet new.  

• Использование командной палитры в VS Code для создания проекта.  

• Выбор шаблона проекта, например, net core empty web для создания пустого веб-проекта.  

• Выбор каталога для создания проекта.  

• Создание папки для проекта, например, game store.  

• Ввод названия проекта, например, "game store api".  

• Два способа просмотра файлов: проводник файлов и обозреватель решений.  

• Обозреватель решений помогает управлять зависимостями и создавать файлы для решения.  

• Обзор файлов проекта, включая файл cs, который запускает приложение и создает экземпляр веб-приложения.  

• Приложение поддерживает множество компонентов, включая вредоносные ПО, службы ведения журнала и внедрения зависимостей.  

• Для настройки сервисов используется объект builder, который позволяет внедрять различные компоненты.  

• При запуске приложения создается экземпляр веб-приложения и настраиваются различные конфигурации, включая установку Kestrel и загрузку конфигураций из файлов и переменных окружения.  

• Конфигурация конвейера запросов определяет, как обрабатывать запросы.  

• В примере показано, как обрабатывать запрос GET, отвечая "привет, мир".  

• Объект приложения позволяет выполнять множество действий при поступлении запросов.  

• Файл проекта определяет тип проекта и целевую платформу.  

• В данном случае используется SDK micros dot net для веб-проектов.  

• Целевая платформа указывает на доступ к API определенной версии .NET SDK.  

• В файле проекта объявляются зависимости и библиотеки для использования в проекте.  

• Конфигурации в формате JSON используются для хранения настроек, которые могут изменяться в разных средах.  

• В разделе "Свойства" есть файл запуска, который предоставляет профили для локальной разработки.  

• Процесс сборки проекта включает компиляцию кода в двоичные файлы.  

• В VS Code можно использовать обозреватель решений для сборки проекта.  

• Скомпилированные библиотеки DLL хранятся в каталоге bin.  

• Для создания проекта используется команда "dotnet".  

• Можно использовать Ctrl+Shift+V для интеграции с задачами сборки VS Code.  

• Для запуска приложения нужно нажать F5 и выбрать отладчик.  

• Отладка позволяет пошагово выполнять код и проверять значения объектов.  

• Можно установить точки останова и продолжить выполнение с помощью кнопки "Воспроизвести".  

• Для запуска без отладки можно использовать проводник решений или терминал.  

• REST API позволяет приложениям взаимодействовать с данными на сервере.  

• API определяет функции, которые клиенты могут использовать для получения данных.  

• REST API следует определенным принципам, таким как передача репрезентативного состояния.  

• Ресурсы в REST API - это объекты, документы или вещи, которые API может получать или отправлять.  

• Ресурсы могут быть размещены на различных доменах и доступны по протоколам HTTP или HTTPS.  

• URI используется для идентификации ресурсов и доступа к ним через REST API.  

• Клиенты отправляют HTTP-запросы на серверы для получения данных.  

• REST API использует методы POST для создания новых ресурсов, GET для получения данных, PUT для обновления и DELETE для удаления.  

• Эти методы позволяют создавать, читать, обновлять и удалять ресурсы.  

• Для запроса всех игр используется метод GET.  

• Ответ содержит статус 200 OK и тело в формате JSON.  

• Для получения конкретной игры добавляется идентификатор ресурса.  

• Для создания игры используется метод POST с телом запроса.  

• Для обновления игры используется метод PUT с новым состоянием ресурса.  

• Для удаления игры используется метод DELETE.  

• Для взаимодействия с API используется Visual Studio Code.  

• Создается файл с расширением .http для взаимодействия с API.  

• Используется расширение Rest Client для написания запросов.  

• Для предотвращения открытия браузера при отладке, режим запуска браузера переключается на false.  

• Это позволяет оставаться в рамках VS Code при отладке.  

• Для управления играми используется объект передачи данных DTO.  

• DTO инкапсулирует данные в стандартизированный формат для передачи между процессами или приложениями.  

• Использование обозревателя решений для создания папок и файлов.  

• Создание новой папки "dt" для DTO.  

• Создание файла "gameDTO" с использованием типа записи.  

• Записи по умолчанию неизменяемы, что идеально для DTO.  

• Сокращение шаблонного кода и упрощение кодовой базы.  

• Типы записей имеют множество преимуществ для DTO.  

• Сопоставление пространства имен с файловой структурой.  

• Объявление свойств: идентификатор, имя, жанр, цена, дата релиза.  

• Подготовка DTO для использования в API.  

• Определение списка игр в памяти с использованием DTO.  

• Реализация методов HTTP для работы с играми.  

• Переход от списка в памяти к реальной базе данных.  

• Объявление списка игр с использованием DTO.  

• Пример списка игр: Street Fighter, Final Fantasy 14, FIFA 23.  

• Указание цен и дат для каждой игры.  

• Определение GET-запроса для получения списка игр.  

• Использование шаблона для реализации GET-запроса.  

• Возвращение списка игр из памяти.  

• Запуск API и проверка работы GET-запроса.  

• Удаление последней точки и проверка работы API.  

• Изменение запроса для работы с API.  

• Получение 200 OK ответа с данными в формате JSON.  

• Преобразование объектов C# в JSON с помощью ядра spin net.  

• Удаление ненужного кода и добавление комментариев для документации.  

• Создание запроса для получения одной игры по идентификатору.  

• Использование метода поиска списков для получения игры по идентификатору.  

• Запуск API и добавление запроса для получения одной игры.  

• Использование трехфунтовых знаков для выделения запроса.  

• Успешное получение игры по идентификатору.  

• Важность использования правильной нотации REST при определении конечных точек.  

• Группировка ресурсов и использование идентификаторов.  

• Переход к созданию новых ресурсов.  

• Создание нового файла DTO для создания игры.  

• Определение свойств DTO: название, производитель, цена, дата выпуска.  

• Удаление идентификатора из DTO, так как он будет предоставлен сервером.  

• Создание конечной точки для публикации новой игры.  

• Преобразование DTO в обычную игру DTO.  

• Добавление новой игры в список и возврат 201 Created response.  

• Использование встроенного класса Results для возврата ответа.  

• Предоставление заголовка местоположения для клиента.  

• Завершение определения новой игры и возврат результата операции.  

• Определение маршрута для клиента, чтобы найти ресурс.  

• Присвоение имени конечной точке "играй, играй, играй".  

• Использование имени в маршруте для создания заголовка местоположения.  

• Указание значения для маршрута getc.  

• Использование анонимного типа для идентификатора.  

• Определение константы для имени конечной точки.  

• Определение запроса для конечной точки post.  

• Указание типа контента application/json.  

• Определение полезной нагрузки для игры.  

• Отправка запроса на создание новой игры.  

• Получение ответа 201 Created с полезной нагрузкой и заголовком местоположения.  

• Клиент может запросить новую игру.  

• Создание новой конечной точки put.  

• Определение DTO для обновления игры.  

• Определение конечной точки put для замены существующей игры.  

• Определение запроса на размещение.  

• Указание идентификатора ресурса для замены.  

• Отправка запроса и получение обновленной игры.  

• Изменение названия игры с "безопасный боец два турбо" на "street fighter two turbo".  

• Повышение цены до 990 долларов.  

• Проверка изменений через запрос к игре с идентификатором.  

• Важность учета параллелизма при работе с играми.  

• Игры хранятся в простом списке, который не является потокобезопасным.  

• Рекомендация использовать параллельные структуры данных для предотвращения проблем.  

• Реализация конечной точки удаления для игр.  

• Использование map delete для удаления игры по идентификатору.  

• Удаление игры с идентификатором и проверка отсутствия контента.  

• Запуск сервера и добавление запроса на удаление.  

• Удаление игры номер два и проверка отсутствия контента.  

• Подтверждение успешного удаления игры через запрос к списку игр.  

• API функционирует, но нужно разобраться с неожиданными сценариями.  

• Пример: что произойдет, если не удастся найти игру?  

• Текущий код возвращает 200 OK и нулевой ответ, что неправильно.  

• Метод должен возвращать правильный ответ в зависимости от наличия игры.  

• Использование явного типа для nullable DTO.  

• Преобразование игры в результаты для корректного возврата.  

• Запуск API и проверка корректного ответа 404 Not Found.  

• Исправление ситуации с запросом "забыть по идентификатору".  

• В случае отсутствия игры, возврат "не найдено".  

• Возможность создания нового ресурса, но это не определено четко.  

• Предпочтение возврата "не найдено" для предотвращения проблем с идентификаторами.  

• Проверка корректного ответа при попытке поместить несуществующую игру.  

• Закрытие темы и остановка сервера.  

• Удаление ресурса, если он существует, или возврат ошибки, если не найден.  

• Клиент не заботится о наличии ресурса, главное - его удаление.  

• Слишком много кода в файле cs, нужно переместить его в другое место.  

• Цель - сделать код максимально чистым и организованным.  

• Создаем новый каталог "конечные точки" в solution explorer.  

• Создаем новый файл "игры и очки" в этом каталоге.  

• Исправляем пространство имен и создаем статический класс с методами расширения.  

• Переносим код из программы cs в новый класс.  

• Создаем список игр, делая его доступным только для чтения.  

• Объявляем метод расширения для класса веб-приложения.  

• Устанавливаем метод как общедоступный статический.  

• Возвращаем веб-приложение.  

• Копируем и вставляем методы из программы cs в метод расширения.  

• Удаляем ненужные действия в программе cs.  

• Используем групповой конструктор для определения общих элементов конечных точек.  

• Изменяем тип возвращаемого значения с веб-приложения на route group.  

• Избегание повторения имен в маршрутах.  

• Пример использования групп маршрутов для GET, POST и DELETE.  

• Проверка работы API с использованием HTTP.  

• Проверка POST-запросов с обязательными полями.  

• Обработка недопустимых данных и возврат ошибки.  

• Пример с нулевым значением для имени.  

• Введение аннотаций к данным для проверки свойств.  

• Пример с обязательным полем "имя" и ограничением длины.  

• Применение аннотаций к другим свойствам, таким как "цена".  

• Необходимость использования фильтров конечных точек в минимальных API.  

• Пример с использованием пакета NuGet для автоматической проверки.  

• Применение фильтров конечных точек для проверки параметров.  

• Добавление ссылки на пакет NuGet для фильтров конечных точек.  

• Применение фильтров к конечным точкам API.  

• Проверка работы API с фильтрами конечных точек и аннотациями данных.  

• Показано сообщение об ошибке с указанием отсутствующего поля.  

• Использование RFC для стандартизированных сообщений об ошибках.  

• Применение проверок ко всем конечным точкам с помощью группы маршрутов.  

• Проверка создания и обновления DTO.  

• Проверка длины имени и обязательного заполнения полей.  

• Проверка цены в диапазоне от 1 до 100.  

• Проверка валидности PUT с обязательным полем "Имя".  

• Завершение проверки конечных точек.  

• Переход к внедрению базы данных с использованием Entity Framework Core.  

• Объяснение метода объектно-реляционного отображения ORM.  

• Проблемы с взаимодействием API и базы данных на разных языках.  

• Преимущества ORM и его роль в упрощении работы с данными.  

• Entity Framework Core как ORM-фреймворк для .NET.  

• Преобразование кода доступа к данным в SQL-инструкции.  

• Преобразование результирующих данных из базы данных в объекты.  

• Преимущества использования Entity Framework Core в сетевых приложениях.  

• Entity Framework Core позволяет выполнять задачи по доступу к данным с помощью знакомого языка C#.  

• Код доступа к данным минимален, так как Entity Framework берет на себя большую часть работы.  

• Интегрированные запросы и ссылки упрощают работу с базами данных.  

• Entity Framework отслеживает изменения в объектах и отправляет их в базу данных при необходимости.  

• Поддержка нескольких поставщиков баз данных позволяет использовать те же модели с другими реляционными базами данных.  

• Первым шагом является определение классов, представляющих модель данных приложения.  

• Использование DTO для этой цели не рекомендуется, так как они должны быть стабильными.  

• Модель данных должна быть гибкой и изменяться в соответствии с таблицами базы данных.  

• Создаем новый каталог "сущности" для хранения модели данных.  

• Добавляем новый файл класса для представления сущности "игра".  

• Определяем свойства для сущностей, включая идентификатор и название.  

• Определяем свойство для связи игры с генератором.  

• Используем реляционную модель для создания ассоциации между игрой и генератором.  

• Добавляем свойства для цены и даты релиза.  

• Устанавливаем пакет NuGet для Entity Framework Core.  

• Используем SQLite в качестве базы данных для упрощения работы.  

• Создаем новый каталог для хранения классов, связанных с данными.  

• Создаем класс контекста базы данных для работы с базой данных.  

• Контекст базы данных представляет сеанс работы с базой данных и используется для запросов и сохранения сущностей.  

• Контекст базы данных сочетает в себе функции единицы работы и репозитория.  

• Получение параметров контекста базы данных.  

• Передача параметров в базовый конструктор.  

• Объявление prop типа db set для сущностей игр и игровых генов.  

• Объяснение, что такое набор баз данных.  

• Создание экземпляров наборов баз данных для игр и игровых генов.  

• Подготовка контекста для отображения объектов в таблицы базы данных.  

• Указание приложению, как подключиться к базе данных SQLite.  

• Регистрация контекста при запуске с использованием builder.  

• Определение строки подключения для SQLite.  

• Entity Framework читает строку подключения и создает экземпляр контекста.  

• Сопоставление параметров контекста с сущностями в таблицах.  

• Проблема с жестко закодированной строкой подключения в коде.  

• Хранение строки подключения в app.json.  

• Поддержка различных источников конфигурации в .NET Core.  

• Объединение информации из всех источников в единый объект конфигурации.  

• Удаление строки подключения из кода.  

• Добавление раздела "строки подключения" в app.json.  

• Чтение строки подключения из app.json с помощью объекта конфигурации.  

• Использование точки останова для проверки значения строки подключения.  

• Подтверждение, что значение считывается из app.json.  

• Приложение готово к взаимодействию с базой данных SQLite.  

• Миграция Entity Framework преобразует объекты модели данных в соответствующие таблицы в базе данных.  

• Для этого нужно установить инструмент dotnet ef.  

• Инструмент dotnet ef позволяет выполнять задачи, связанные с Entity Framework.  

• Инструмент dotnet ef устанавливается как глобальный инструмент.  

• Для создания миграций Entity Framework используется пакет Microsoft Entity Framework Core.  

• Пакет устанавливается в проект API.  

• Создается папка для миграций в каталоге данных.  

• Выполняется команда dotnet ef migrations init для создания первой миграции.  

• Миграция создает файлы в каталоге миграций.  

• Файл миграции содержит методы up и down.  

• Метод up создает таблицы и устанавливает ограничения.  

• Метод down удаляет таблицы и восстанавливает базу данных.  

• Для применения миграции используется команда dotnet ef update database.  

• Entity Framework создает таблицу истории миграций и применяет новую миграцию.  

• Создаются таблицы для моделей данных, такие как таблицы щедрых и игр.  

• Создание индексов и установка нового значения в истории миграции EF.  

• Проверка создания базы данных через обозреватель решений.  

• Файл базы данных создается в каталоге api проекта.  

• Возможность перемещения файла базы данных в другой каталог.  

• Исключение файла базы данных из git-коммита.  

• Использование расширения SQLite для VS Code для работы с базой данных.  

• Открытие базы данных через SQLite Explorer.  

• Обзор структуры таблиц: гены, игры, история миграции EF.  

• Таблица истории миграции EF отслеживает все выполненные миграции.  

• Добавление кода для применения миграций при запуске приложения.  

• Создание статического класса с методом расширения для миграции базы данных.  

• Использование внедрения зависимостей для доступа к контексту базы данных.  

• Удаление базы данных и проверка автоматического воссоздания при запуске приложения.  

• Выполнение миграции при запуске приложения.  

• Упрощение ведения журнала для уменьшения количества инструкций при запуске.  

• Добавление записи в раздел "вход" для настройки ведения журнала.  

• Изменение строгости ведения журнала для элементов приложения.  

• Исключение информационных сообщений и отображение только предупреждений и ошибок.  

• Настройка уровня журнала для специфического пространства имен.  

• Использование war для отображения только предупреждений, ошибок и критических сообщений.  

• Удаление базы данных и запуск dotnet для проверки изменений.  

• Возможность отображения всех команд при использовании JSON.  

• Очистка командной строки для более чистого интерфейса.  

• Переход к физическому флаттеру и концепции игровых категорий.  

• Добавление нового метода для заполнения статичных данных.  

• Использование метода onmodelcreating для изменения модели.  

• Заполнение категорий при запуске приложения.  

• Добавление новой миграции для сопоставления данных с базой данных.  

• Использование команды dotnet ef migrations для создания новой миграции.  

• Проверка новой миграции в проводнике и SQLite Explorer.  

• Объяснение концепции внедрения зависимостей.  

• Пример с классами myservice и mylogger.  

• Преимущества внедрения зависимостей для тестирования и модуляции.  

• Проблемы, возникающие при жесткой связи между классами.  

• Необходимость изменения сервиса при изменении регистратора.  

• Преимущества внедрения зависимостей для модульного тестирования.  

• Service Container в .NET Core позволяет регистрировать зависимости во время запуска.  

• При поступлении нового HTTP-запроса контейнер создает и внедряет зависимости в новый экземпляр сервиса.  

• Это позволяет избежать изменений в сервисе при изменении его зависимостей.  

• Инверсия зависимостей позволяет коду зависеть от абстракций, а не от конкретных реализаций.  

• Пример: замена регистратора с mylogger на cloud logger без изменения сервиса.  

• Использование интерфейса позволяет легко заменять зависимости без изменения кода.  

• Важно понимать, как долго сервис должен существовать.  

• Существуют три типа срока службы: transient, scope и singleton.  

• Transient создает новый экземпляр для каждого запроса, scope использует один экземпляр для запроса, singleton использует один экземпляр на все время работы приложения.  

• Пример использования внедрения зависимостей и сроков службы для контекста базы данных.  

• Регистрация контекста базы данных с ограниченным сроком службы гарантирует создание нового экземпляра для каждого запроса.  

• Это улучшает управление подключениями к базе данных и обеспечивает согласованность данных в транзакциях.  

• Повторное использование dbcontext может увеличить использование памяти.  

• Наличие срока службы области видимости снижает нагрузку на память.  

• Регистрация контекста gamestore как службы области видимости.  

• Введение экземпляра контекста gamestore в обработчик метода.  

• Использование контекста для создания сущностей.  

• Объявление свойств новой игры и назначение идентификатора генератора.  

• Объявление названия и пола игры.  

• Изменение dto для получения правильного идентификатора генератора.  

• Назначение жанра и пола игре с использованием контекста.  

• Добавление новой сущности в контекст базы данных.  

• Использование метода "добавить" для добавления новой игры.  

• Сохранение изменений для вставки новой записи в базу данных.  

• Запуск сети и переход к конечным точкам игр.  

• Изменение метода post для отправки идентификатора генератора.  

• Отправка запроса и исправление ошибки проверки цены.  

• Создана новая игра "Minecraft" с идентификационным номером один.  

• Проверка существования игры в базе данных SQLite.  

• Обнаружена проблема с изменением контракта на ответ клиенту.  

• Изменение контракта на ответ клиенту.  

• Клиент должен отправлять общий идентификатор.  

• Решение: возвращать DTO вместо внутренних объектов.  

• Преобразование игры в DTO для возврата клиенту.  

• Заполнение полей свойств DTO.  

• Использование оператора null для проверки значения.  

• Перезапуск сервера и создание новой игры "Street Fighter 2".  

• Проверка корректного создания игры и сохранения контракта с клиентом.  

• Важность разделения между DTO и моделью данных.  

• Метод стал слишком большим и требует оптимизации.  

• Создание сущности из новой игры, создание DTO и сохранение в базе данных.  

• Создание логики отображения для упрощения кода.  

• Использование картографической библиотеки AutoMapper или простого метода расширения.  

• Создание нового каталога и файла для сопоставления.  

• Объявление статического класса и методов расширения.  

• Создание метода для отображения DTO в сущность и наоборот.  

• Копирование логики из конечных точек в методы расширения.  

• Упрощение кода и удаление ненужных частей.  

• Проверка работы методов расширения через тестирование.  

• Добавление контекста базы данных в лямбду.  

• Использование метода поиска для нахождения объекта в контексте базы данных.  

• Возвращение DTO вместо модели данных для улучшения пользовательского интерфейса.  

• Создание нового DTO для метода get by id.  

• Добавление идентификатора генератора для использования в пользовательском интерфейсе.  

• Копирование и модификация существующего DTO для нового метода.  

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

• Вносим изменения в игровое картографирование.  

• Создаем новый метод для отображения информации о техническом директоре игры.  

• Исправляем ошибки компиляции.  

• Возвращаем идентификатор игры вместо строки.  

• Тестируем новый метод для получения игры по идентификатору.  

• Изменяем DTO для обновленной игры, чтобы использовать идентификатор.  

• Определяем метод для сопоставления обновленной игры с сущностью.  

• Добавляем параметр для идентификатора в метод обновления.  

• Находим существующую игру в контексте базы данных.  

• Заменяем существующую запись новой сущностью.  

• Используем контекст базы данных для сохранения изменений.  

• Преобразуем обновленную игру в сущность.  

• Используем метод расширения для создания сущности.  

• Сохраняем изменения в базе данных.  

• Обновление игры "Street Fighter 2 Turbo" с измененной ценой.  

• Ошибка при обновлении: забыт идентификатор жанра.  

• Успешное обновление после исправления ошибки.  

• Остановка сервера и подготовка к изменению конечных точек.  

• Получение контекста магазина игр и преобразование игр в DTO.  

• Оптимизация для повышения эффективности.  

• Запуск сервера и тестирование конечной точки GET.  

• Проверка корректного отображения игр и их идентификаторов.  

• Подготовка к операции удаления.  

• Введение контекста магазина игр и удаление объекта.  

• Использование пакетного удаления для эффективной работы.  

• Тестирование удаления игры и проверка успешности операции.  

• Удаление списка игр из памяти.  

• Переход к изучению асинхронной модели программирования.  

• Пример приготовления завтрака: разогрев сковороды, обжаривание яиц, приготовление тостов, добавление джема и арахисового масла, добавление апельсинового сока.  

• Синхронный подход: выполнение задач последовательно, одна за другой.  

• Асинхронный подход: выполнение задач параллельно, переключение между ними.  

• Асинхронное программирование позволяет обрабатывать запросы параллельно.  

• Веб-сервер Kestrel обрабатывает запросы асинхронно, освобождая ресурсы для других задач.  

• Преимущества: повышение производительности, масштабируемость, простота использования.  

• Изменение взаимодействия с базой данных для возврата задач вместо объектов.  

• Использование асинхронных методов и ключевых слов async и await.  

• Преобразование всех операций в асинхронный режим для повышения производительности.  

• Преобразование методов GET, POST, PUT и DELETE в асинхронный режим.  

• Ожидание выполнения задач, выходящих за рамки процесса, таких как сохранение изменений в базе данных.  

• Использование соглашения об асинхронности для упрощения написания кода.  

• Выполнение отложенных миграций асинхронно при запуске приложения.  

• Изменение метода миграции для возврата задачи вместо стандартного объекта.  

• Использование суффикса async для методов, выполняющих асинхронные операции.  

• Метод является асинхронным, так как возвращает задачу.  

• Необходимо дождаться выполнения задачи перед переходом к следующему шагу.  

• Для использования модели программирования для одиночек нужно дождаться завершения задачи.  

• Удаление базы данных и перезапуск приложения.  

• Миграции применены успешно, база данных восстановлена.  

• Тестирование операции POST и GET для проверки работы конечных точек.  

• Остановка сервера и завершение работы с конечными точками игр.  

• Интеграция конечных точек в современный веб-клиент.  

• Необходимость создания конечной точки для запросов к генам для элементов пользовательского интерфейса.  

• Создаем новый DTO для представления данных.  

• Определяем отображение для преобразования общей сущности в DTO.  

• Создаем класс картографирования для методов расширения.  

• Создаем класс конечных точек для генов.  

• Определяем группу маршрутов и конечную точку для запроса данных.  

• Используем асинхронную операцию для запроса данных.  

• Используем контекст базы данных для восстановления данных.  

• Преобразуем данные в DTO и возвращаем асинхронный результат.  

• Тестируем конечную точку, добавляя новый запрос в файл http.  

• Создаем клиентское приложение для взаимодействия с API.  

• Настраиваем интерфейс для взаимодействия с API.  

• Тестируем создание и обновление игр через интерфейс.  

• Демонстрируем создание и обновление игр через интерфейс.  

• Подтверждаем успешное сохранение данных в базе данных.  

• Подводим итоги и благодарим за просмотр.