Перейти к содержанию

M2: Персистентность — EF Core + PostgreSQL

На M2 проект защиты учится сохранять данные. Результат парсера из M1 (граф объектов в памяти) записывается в PostgreSQL и переживает перезапуск приложения. Для этого подключается EF Core и концепция миграций.

⚠️ Уровень детализации. Постановка задачи и целевые навыки зафиксированы. Конкретные шаги реализации (структура DbContext, состав конфигураций сущностей, форма тестов) — самостоятельное решение стажёра на основе материалов. Снять пометку и уточнить детали можно после сверки с intern-development-strategy-design.md.

Срок

Месяц 3 Фазы 1 (~40–60 часов).

Цель

Подключить к проекту защиты PostgreSQL через EF Core. Настроить схему БД так, чтобы доменные классы из M1 (Project, Borehole, Sample, Sample_Lab, ParameterValue) сохранялись и читались. Создать миграции.

Целевые навыки

Группа Что осваивается
EF Core: основы DbContext, DbSet<T>, Add, Update, Remove, SaveChangesAsync
Конфигурация через Fluent API OnModelCreating, ToTable, HasKey, Property, связи по FK
Миграции dotnet ef migrations add, database update. Жизненный цикл миграций
Прямой доступ к DbContext Без обёрток Repository/UnitOfWork — это конвенция команды DeepGeo
DDD: FK без навигационных свойств Схема БД отражает домен: связи только по FK, без cross-aggregate navigation
Асинхронность async/await в методах работы с БД (ToListAsync, FirstOrDefaultAsync)
Тесты персистентности Интеграционные тесты: in-memory provider или тестовая БД

Технологии на M2

  • Microsoft.EntityFrameworkCore (версия 8.x)
  • Npgsql.EntityFrameworkCore.PostgreSQL — провайдер PostgreSQL
  • Microsoft.EntityFrameworkCore.Design — для миграций

Задание

Постановка

Настроить персистентность так, чтобы:

  • результат парсера из M1 (полный граф доменных объектов) можно было сохранить в PostgreSQL одной операцией;
  • после перезапуска приложения данные читались из БД и совпадали с сохранёнными;
  • схема БД создавалась миграцией, применимой к чистой БД одной командой.

Требования к результату

DbContext

Создать класс DbContext, предоставляющий доступ ко всем пяти агрегатам. Решить самостоятельно:

  • как именно реализован класс (наследование, конструктор, переопределение OnModelCreating);
  • в виде одного метода OnModelCreating или через отдельные классы-конфигурации сущностей (IEntityTypeConfiguration) — оба варианта допустимы;
  • как именно настраивать каждую сущность (имена таблиц, типы колонок, ограничения).

Конвенция команды DeepGeo: прямой доступ к DbContext, без обёрток Repository/UnitOfWork. Это сознательное решение, его нужно соблюдать в проекте защиты.

Схема БД

Схема должна отражать домен и соблюдать DDD-конвенцию «только FK»:

  • между агрегатами — только FK-колонки, без cross-aggregate navigation properties на уровне EF;
  • типы колонок адекватны данным (например, дробные значения — не целые);
  • обязательные поля помечены как NOT NULL;
  • первичные ключи настроены корректно.

Миграции

Создать минимум одну миграцию, которая:

  • создаёт полную схему с нуля;
  • применяется к чистой БД через dotnet ef database update без ошибок;
  • не требует ручного доведения SQL после применения.

End-to-end сценарий

После завершения M2 должна работать цепочка:

  1. Запустить парсер из M1 на тестовом файле.
  2. Сохранить результат в БД через DbContext.
  3. Перезапустить приложение.
  4. Прочитать данные из БД.
  5. Убедиться, что прочитанные данные совпадают с тем, что было сохранено (включая связи по FK).

Тесты

Написать интеграционные тесты, проверяющие:

  • сохранение и чтение графа объектов (хотя бы базовый сценарий);
  • корректность связей по FK после чтения из БД.

Как именно организовать тестовую БД (in-memory provider, отдельная тестовая БД, тестовый контейнер) — самостоятельное решение. Обосновать выбор в README или в комментарии к тестам.

Инженерная культура

  • Строка подключения — в appsettings.json (не хардкод в коде).
  • Миграции в git, не в .gitignore.
  • Коммиты осмысленные, ветки под задачи.

Контрольная точка

В конце месяца 3 — встреча с наставником:

  • показать применение миграции к чистой БД;
  • продемонстрировать end-to-end сценарий (парсер → БД → чтение после перезапуска);
  • показать интеграционные тесты;
  • объяснить выбор организации тестовой БД.

Чек-лист завершения M2

  • DbContext создан, охватывает все 5 сущностей
  • Конфигурация через Fluent API
  • Миграция создана и применяется к чистой БД
  • Парсер → DbContext → SaveChanges → перезапуск → чтение работает
  • Интеграционные тесты проходят
  • Строка подключения в appsettings.json, не в коде
  • Схема соблюдает DDD-конвенцию (только FK между агрегатами)

Материалы по темам

EF Core — основы

Конфигурация моделей

Миграции

PostgreSQL-провайдер

Асинхронность в EF Core

Тестирование с EF Core

Прогресс

[■■■□□] M2 из 5 вех — данные переживают перезапуск.

📚 Полный список ресурсов — в разделе Ресурсы.