Переносы баз данных для Entity Framework 4

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

Ответы

Ответ 1

Это скоро появится как пакет NuGet под названием EntityFramework. Миграции

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

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

migrate -script

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

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

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

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

Ответ 2

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

Ответ 3

ScottGu упоминает об этом в записи в блоге:

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

[EDIT]

Я думаю, что он может ссылаться на блок создания баз данных Entity Designer, как ответил Мортеза Манави в другой ответ SO > .

Ответ 4

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

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

Ответ 5

Я работаю над альтернативой библиотеке EF.Migrations - EntityFramework.SchemaCompare. Это позволяет физически сравнивать схему db с моделью сущностей, представляющей контекст базы данных (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