Реализация проекта сервисно-ориентированного приложения.
- Реализация объектно-ориентированной модели данных,
- Изучение реализации серверных приложений на базе WebAPI/OpenAPI,
- Изучение работы с брокерами сообщений,
- Изучение паттернов проектирования,
- Изучение работы со средствами оркестрации на примере .NET Aspire,
- Повторение основ работы с системами контроля версий,
- Unit-тестирование.
1. «Классы» - Реализация объектной модели данных и unit-тестов
В рамках первой лабораторной работы необходимо подготовить структуру классов, описывающих предметную область, определяемую в задании. В каждом из заданий присутствует часть, связанная с обработкой данных, представленная в разделе «Unit-тесты». Данную часть необходимо реализовать в виде unit-тестов: подготовить тестовые данные, выполнить запрос с использованием LINQ, проверить результаты.
Хранение данных на этом этапе допускается осуществлять в памяти в виде коллекций.
Необходимо включить как минимум 10 экземпляров каждого класса в датасид.
2. «Сервер» - Реализация серверного приложения с использованием REST API
Во второй лабораторной работе необходимо реализовать серверное приложение, которое должно: - Осуществлять базовые CRUD-операции с реализованными в первой лабораторной сущностями - Предоставлять результаты аналитических запросов (раздел «Unit-тесты» задания)
Хранение данных на этом этапе допускается осуществлять в памяти в виде коллекций.
3. «ORM» - Реализация объектно-реляционной модели. Подключение к базе данных и настройка оркестрации
В третьей лабораторной работе хранение должно быть переделано c инмемори коллекций на базу данных. Должны быть созданы миграции для создания таблиц в бд и их первоначального заполнения.
Также необходимо настроить оркестратор Aspire на запуск сервера и базы данных.
4. «Инфраструктура» - Реализация сервиса генерации данных и его интеграция с сервером
В четвертой лабораторной работе необходимо имплементировать сервис, который генерировал бы контракты. Контракты далее передаются в сервер и сохраняются в бд. Сервис должен представлять из себя отдельное приложение без референсов к серверным проектам за исключением библиотеки с контрактами. Отправка контрактов при помощи gRPC должна выполняться в потоковом виде. При использовании брокеров сообщений, необходимо предусмотреть ретраи при подключении к брокеру.
Также необходимо добавить в конфигурацию Aspire запуск генератора и (если того требует вариант) брокера сообщений.
5. «Клиент» - Интеграция клиентского приложения с оркестратором
В пятой лабораторной необходимо добавить в конфигурацию Aspire запуск клиентского приложения для написанного ранее сервера. Клиент создается в рамках курса "Веб разработка".
Обязательно:
- Реализация серверной части на .NET 8.
- Реализация серверной части на ASP.NET.
- Реализация unit-тестов с использованием xUnit.
- Использование хранения данных в базе данных согласно варианту задания.
- Оркестрация проектов при помощи .NET Aspire
- Реализация сервиса генерации данных при помощи Bogus и его взаимодейсвие с сервером согласно варианту задания.
- Автоматизация тестирования на уровне репозитория через GitHub Actions.
- Создание минимальной документации к проекту: страница на GitHub с информацией о задании, скриншоты приложения и прочая информация.
Факультативно:
- Реализация авторизации/аутентификации.
- Реализация atomic batch publishing/atomic batch consumption для брокеров, поддерживающих такой функционал.
- Реализация интеграционных тестов при помощи .NET Aspire.
- Реализация клиента на Blazor WASM.
Внимательно прочитайте дискуссии о том, как работает автоматическое распределение на ревью. Сразу корректно называйте свои pr, чтобы они попали на ревью нужному преподавателю.
По итогу работы в семестре должна получиться следующая информационная система:
Номер варианта задания присваивается в начале семестра. Изменить его нельзя. Каждый вариант имеет уникальную комбинацию из предметной области, базы данных и технологии для общения сервиса генерации данных и сервера апи.
Список вариантов
Список предметных областей
На каждую из лабораторных работ необходимо сделать отдельный Pull Request (PR).
Общая схема:
- Сделать форк данного репозитория
- Выполнить задание
- Сделать PR в данный репозиторий
- Исправить замечания после code review
- Получить approve
- Прийти на занятие и защитить работу
Конкурентный принцип. Так как задания в первой лабораторной будут повторяться между студентами, то выделяются следующие показатели для оценки:
- Скорость разработки
- Качество разработки
- Полнота выполнения задания
Быстрее делаете PR - у вас преимущество. Быстрее получаете Approve - у вас преимущество. Выполните нечто немного выходящее за рамки проекта - у вас преимущество.
- 3 балла за качество кода, из них:
- 2 балла - базовая оценка
- 1 балл (но не более) можно получить за выполнение любого из следующих пунктов:
- Реализация факультативного функционала
- Выполнение работы раньше других: первые 5 человек из каждой группы, которые сделали PR и получили approve, получают дополнительный балл
- 3 балла за защиту: при сдаче лабораторной работы вам задается 3 вопроса, за каждый правильный ответ - 1 балл
У вас 2 попытки пройти ревью (первичное ревью, ревью по результатам исправления). Если замечания по итогу не исправлены, то снимается один балл за код лабораторной работы.
Чтобы задать вопрос по лабораторной, воспользуйтесь соотвествующим разделом дискуссий или заведите ишью.
Если у вас появились идеи/пожелания/прочие полезные мысли по преподаваемой дисциплине, их можно оставить здесь.