Миграция базы данных для Entity Framework 4

Question

Я играл с Entity Framework 4, используя подход на основе модели для создания сценария базы данных из моих сущностей.Это здорово, но я не уверен, как это работает, когда дело доходит до управления версиями базы данных.Я предполагаю, что если бы я хотел использовать среду миграции активного типа записи, мне пришлось бы действовать наоборот и генерировать объекты из моей базы данных?Есть ли способ использовать подход, основанный на модели, и правильно установить версию базы данных?

Answer 1

Скоро это появится в виде пакета NuGet под названием EntityFramework.Migrations.

Демонстрацию провел Скотт Хансельман на конференции TechEd 2011 (доступно онлайн по адресу). http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV349).Соответствующий раздел на 45-й минуте.

Короче говоря, как только пакет будет установлен, вы введете следующее в консоль диспетчера пакетов, чтобы сгенерировать сценарий изменения базы данных:

migrate -script

ОБНОВЛЕНИЕ (13 ноября 2011 г.)

Альфа-версия 3 этого пакета теперь доступна на NuGet.Вместо использования командлета migrate -script упомянутый выше, он использует командлет Add-Migration <migrationname>.А пошаговое руководство по его использованию можно найти в блоге группы ADO.NET.

ОБНОВЛЕНИЕ (14 февраля 2012 г.)

Эта функция теперь доступна как часть основного Пакет NuGet EntityFramework, начиная с версии 4.3.Ан обновленное прохождение с использованием EF 4.3 можно найти в блоге группы ADO.NET.

Answer 2

Можешь попробовать Ворота: Это инструмент для управления миграциями базы данных. Он не интегрируется с EF (поскольку почти невозможно интегрировать с ним в этом отношении), но делает работу.

Answer 3

Скотту упоминает что-то об этом в запись в блоге:

Мы также будем поддерживать функцию «миграции» с EF в будущем, что позволит вам автоматически автоматизировать / сценарию схемы базы данных программно.

РЕДАКТИРОВАТЬ

Я думаю, что он может быть направлен на Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power Power, как ответил Мортеза Манави в другой, так что ответить.

Answer 4

Ну, если вы хотите работать как ActiveRecord, то вам нужно работать как ActiveRecord. :)

Однако, если вы хотите использовать модель - сначала, но все еще используют миграции, это будет возможно, но потребуется дополнительная работа от вашего имени. Model - сначала будет генерировать сценарий изменения базы данных. Вам придется извлечь соответствующие части в миграцию, а также вручную записи сценариев отмены. Хотя это включает в себя какой-то ручной труд, это не поражает меня как ужасно сложно.

Answer 5

Я работаю на альтернативе библиотеке EF.Migrations - EntityFramework.schemacompare.. Отказ Это позволяет физически сравнивать схему БД с модельной моделью субъектов, представляющих контекст базы данных (EF.Migrations не делает этого). Это может быть уволено либо во время инициализации базы данных или вручную по запросу. Рассмотрим следующий пример

#if DEBUG
Database.SetInitializer(new CheckCompatibilityWithModel<DatabaseContext>());
#endif

Он будет выбрасывать исключение во время инициализации базы данных, описывающие различия между схемой DB и моделью, если обнаружены проблемы несовместимости. В качестве альтернативы вы можете найти эти различия в любое время в вашем коде таким образом

using (var ctx = new DatabaseContext())
{
    var issues = ctx.Database.FindCompatibilityIssues();
}

Тогда имея эти различия / проблемы несовместимости на руках, вы можете либо обновить схему БД или модели.

Этот подход особенно полезен, когда вам нужен полный контроль над схемы и дизайном модели базы данных и / или работать в команде, где несколько членов команды работают над одной и той же схемой и моделью DB. Он также может быть использован в дополнение к EF.Migrations.

Вилка меня в Github: https://github.com/kriasoft/data.