EF Core

DbContext — это сессия работы с базой: он держит модель, соединение и change tracker, а SaveChanges разом отправляет накопленные правки. Каждое свойство DbSet<T> — это queryable-коллекция одного типа сущности и точка входа для Add и Remove по нему.

Отслеживаемый запрос кладёт каждую сущность в ChangeTracker со снимком её исходных значений и разрешает identity, так что один ключ даёт один экземпляр. SaveChanges сравнивает снимки с текущими значениями и строит UPDATE. AsNoTracking пропускает снимок и identity resolution — чтение дешевле, но такие сущности уже не сохранить.

builder.Services.AddDbContext<AppDbContext>(...) регистрирует контекст и настраивает его провайдер. Регистрация — scoped: контейнер создаёт один экземпляр на запрос и освобождает его вместе со scope. Сервис принимает AppDbContext параметром конструктора и не создаёт его через new.

Он накапливает все добавления, изменения и удаления своих отслеживаемых сущностей и фиксирует их вместе: один SaveChanges открывает транзакцию, записывает всё разом и при сбое всё откатывает. Поэтому AddDbContext регистрирует его как Scoped — один контекст на запрос означает одну единицу работы на запрос, уничтожаемую вместе со scope.

Один запрос загружает N родителей, а затем обращение к навигации каждого из них порождает ещё по одному запросу — N+1 обращений к базе вместо одного. Загружайте связанные данные тем же запросом: Include для всего графа или проекция Select только по нужным колонкам. Обычная причина — lazy loading, поэтому в API его отключают.

Eager loading тянет связь внутри исходного запроса — через Include. Explicit loading подтягивает её позже по требованию, вызовом Entry(...).Collection(...).Load() — это одно лишнее обращение, о котором вы попросили сами. Lazy loading тянет её в момент чтения проксированной навигации: неявно, и это классический источник N+1.

Она строит модель из вашего DbContext, сравнивает её со снимком модели от предыдущей миграции и генерирует C#-класс миграции с Up и Down плюс обновлённый снимок. Базы она не касается вовсе — SQL выполнится позже, при dotnet ef database update или вызове Migrate() на старте.

Компилируется каждый запрос: провайдер обходит дерево выражений, вычисляет по нему ключ кэша и ищет план в своём кэше запросов. Скомпилированный запрос делает это один раз и отдаёт делегат, поэтому обход дерева и поиск в кэше исчезают из каждого последующего вызова. Он оправдан для горячих, часто исполняемых запросов фиксированной формы — структура не может меняться от вызова к вызову.

Свойство настраивают через IsRowVersion(): значение, прочитанное вместе с сущностью, попадает в WHERE сгенерированного UPDATE. Если другая транзакция успела изменить строку, версия уже не совпадает, затронуто ноль строк, и SaveChanges бросает DbUpdateConcurrencyException. Дальше вы перечитываете текущие значения и повторяете, сливаете или показываете конфликт.

В логе один запрос за 50 заказов и затем по запросу на строки каждого заказа — 51 обращение к базе. Это N+1 из-за навигации, разрешаемой лениво внутри цикла; каждая команда быстрая, поэтому дело не в SQL, а в их количестве. Загрузите строки тем же запросом через Include или проекцию Select, отключите lazy loading и добавьте AsNoTracking, чтобы снять стоимость отслеживания на эндпоинте только для чтения.

Не переименовывайте на месте — сначала expand, затем contract, за три деплоя. Деплой 1 добавляет nullable FullName, пишет в обе колонки и читает Name. Старые строки заполняются пачками, чтобы не брать долгую блокировку. Деплой 2 читает FullName и всё ещё пишет в обе, когда заполнение проверено. Деплой 3 делает FullName non-nullable и удаляет Name. Каждый шаг аддитивен, работает при обеих живых сборках и откатывается сам по себе.