Для чего нужна пустая миграция в Entity Framework

Что проверяют

Работали ли вы с миграциями дальше migrations add по изменению модели. Интервьюер ждёт сценарии, где изменение схемы моделью не описать, и знание разницы между EF6 и EF Core. Следом часто спрашивают, как перенести данные при переименовании колонки.

Как отвечать

Пустая миграция получается, когда вы добавляете её без изменений в модели: dotnet ef migrations add AddReportView или Add-Migration в консоли диспетчера пакетов. Методы Up() и Down() пустые, заполняете их вы. Зачем это нужно:

• произвольный SQL: migrationBuilder.Sql(...) для представлений, хранимых процедур, функций, триггеров, расширений PostgreSQL, то есть всего, чего нет в модели;
• миграция данных: заполнить новую колонку, разнести значения по таблицам, поправить справочники. Лучше отдельной миграцией после той, что меняет схему;
• baseline для существующей базы: в EF6 для этого есть Add-Migration Initial -IgnoreChanges, он пишет снимок модели без операций. В EF Core такого флага нет: генерируют начальную миграцию, очищают её Up() и применяют, либо вручную добавляют строку в __EFMigrationsHistory;
• операции вне транзакции: у Sql() есть параметр suppressTransaction для команд, которые в транзакции не выполняются.

Такая миграция остаётся полноценной: попадает в историю, едет в идемпотентный скрипт dotnet ef migrations script --idempotent и в migrations bundle, поэтому одинаково применяется на всех стендах.

Где спотыкаются

Оставляют Down() пустым. Откат молча проходит, представление или триггер остаются в базе, и повторное применение миграции падает.

Используют в миграции данных классы сущностей и DbContext. Через полгода модель поменяется, и старая миграция перестанет компилироваться или сделает не то. Внутри миграции надёжнее чистый SQL.

Путают EF6 и EF Core и советуют -IgnoreChanges в проекте на EF Core, где такого параметра нет. Прежде чем называть команды, уточните, о какой версии речь.