Ответ
Миграция в Entity Framework Core — это механизм для управления изменениями схемы базы данных с помощью кода C#. Вместо ручного написания SQL-скриптов для создания или изменения таблиц, вы описываете изменения в модели данных, а EF Core генерирует и применяет соответствующие команды к БД.
Ключевые моменты:
- Файлы миграций хранятся в проекте и содержат два основных метода:
Up()— применяет изменения к БД.Down()— откатывает эти изменения.
- Версионирование: Каждая миграция представляет собой отдельный шаг, что позволяет отслеживать историю изменений схемы и согласовывать её между средами разработки, тестирования и продакшена.
-
Инструменты CLI: Основные команды для работы:
# Создать новую миграцию на основе изменений в моделях dotnet ef migrations add <MigrationName> # Применить все ожидающие миграции к базе данных dotnet ef database update # Откатить последнюю применённую миграцию dotnet ef database update <PreviousMigrationName>
Практический пример:
- Вы добавляете новое свойство
Emailв класс сущностиUser. - Выполняете
dotnet ef migrations add AddEmailToUser. EF Core сравнивает текущую модель с состоянием БД и создаёт файл миграции с кодом для добавления столбцаEmail. - Выполняете
dotnet ef database update, чтобы применить этот SQL-скрипт к вашей базе данных.
Best Practice: Миграции следует создавать для каждого значимого изменения модели и включать в систему контроля версий (например, Git).
Ответ 18+ 🔞
Слушай, ну это ж просто праздник какой-то, а не работа! Раньше, блядь, как было? Сидишь, пишешь эти бесконечные SQL-скрипты вручную: ALTER TABLE Users ADD COLUMN Email NVARCHAR(100) NULL. А потом ещё на проде забываешь применить, и всё, пиздец — приложение падает с дурацкой ошибкой про отсутствующий столбец.
А теперь, представляешь, просто добавляешь свойство Email в класс User в коде, как будто так и надо. Потом делаешь одну команду в консоли — и всё, блядь! Фреймворк сам соображает, что к чему, и генерирует нужный SQL. Это же просто ёбушки-воробушки, ей-богу!
Вот как это работает, если по-простому:
- Файлы миграций — это как черновики для базы данных. Лежат у тебя в проекте, и в каждом два главных метода:
Up()— говорит базе: «Слушай сюда, дружок, сделай вот это и вот это». Добавь столбец, создай таблицу — всё дела.Down()— это на случай, если всё пошло по пизде. Он откатывает изменения изUp(). Накосячил — откатился, и нет проблем.
- История изменений: Каждая миграция — это отдельный шажок. Можно посмотреть, что и когда менялось. Это ж удобно до охуения! Не надо гадать, какая версия схемы у тебя на тестовом сервере.
-
Команды, которые спасают жизнь: Вся магия в консоли.
# Добавил свойство в класс? Даёшь команду — и миграция готова. dotnet ef migrations add AddEmailToUser # Хочешь применить всё это добро к реальной базе? Без проблем! dotnet ef database update # Обосрался и надо откатить последнее изменение? Легко! dotnet ef database update <ИмяПредыдущейМиграции>
Пример из жизни, чтобы вообще всё стало ясно:
- Ты такой: «О, а пусть у пользователя будет почта!» — и пишешь
public string Email { get; set; }в классUser. - Летишь в консоль и делаешь
dotnet ef migrations add AddEmailToUser. EF Core такой: «Ага, я вижу, тут новыйEmailпоявился. Ща сгенерирую, как его в таблицу впихнуть». - Командуешь
dotnet ef database update— и вуаля! Столбец в базе появился, можно работать. Ни одного SQL-запроса руками не писал. Красота!
Главный совет, чтоб не вышло боком: Создавай миграцию для каждого логического изменения и обязательно заливай эти файлы в Git. Это как документы на машину — должны быть в порядке. Иначе потом будешь сидеть и ебать котелок: «А почему у Васи на локале работает, а на сервере — нет?». А потому что миграцию в коммит забыл положить, вот почему!
