Как мне перейти от кода EF сначала к более традиционной стратегии развития? - PullRequest
2 голосов
/ 27 апреля 2011

В настоящее время я разрабатываю небольшое приложение с EFCF (сначала код EF) и MVC3.Кажется, что EFCF отлично подходит для разработки прототипа или приложения v1.Что происходит с моими развернутыми базами данных после выпуска v1?Как бы я пошел о развертывании v1 ++?В частности, DB.

С EFCF у меня есть 2 режима, воссоздать, если они разные, или пересоздать всегда.Нет режима "diff", который бы сохранял мои данные и исправлял изменения модели.Как бы я пошел по этому поводу?Я полагаю, что я мог бы сравнить БД v1 с БД v1 ++ и пойти по этому пути, или я мог бы перейти от EFCF и перейти к более традиционному маршруту изменения БД, а затем обновить свои POCO для отражения изменений.Проблема в том, что я не совсем понимаю последнее и не смог составить подходящий запрос Google.

Ответы [ 4 ]

3 голосов
/ 27 апреля 2011

Любой автоматический инструмент для переноса данных - это то, что никогда не должно касаться вашей производственной базы данных.Код-первый подход для разработки.Вы должны отключить создание базы данных после того, как переместите свой код в рабочую среду, и вы должны создать сценарий изменения для базы данных при обновлении до новой версии.Вы можете использовать некоторые вспомогательные инструменты для создания сценария diff, например, инструменты VS Database (VS 2010 Premium или Ultimate) или Red Gate.

2 голосов
/ 27 апреля 2011

2 ссылки:

  1. Создание моделей из базы данных
  2. Еще одна статья с более подробной информацией

Этот метод генерирует все классы из схемы базы данных.Здесь вы можете изменить схему базы данных.Единственное, что вам нужно будет сделать, это обновить модель данных вашей сущности, но это не повлияет на ваши данные и не должно нарушать ваш код, если вы не удаляете поля.

1 голос
/ 27 апреля 2011

Похоже, EFCF отлично подходит для разработки прототипа или приложения v1.

Bingo.В настоящее время EF4.1 не имеет реальных возможностей управления версиями, хотя они работают над «миграциями» и «эволюцией схемы».Проверьте "Что не поддерживается" здесь .

Лично мне очень нравится отображение кода, и поэтому я рекомендую, чтобы, как только ваша первоначальная схема была создана, вы вносили будущие изменения (а) изменение вашей базы данных, (б) изменение ваших POCO, а затем (в) изменение ваших отображений в коде.Конечно, вы бы сказали, чтобы объект базы данных никогда не удалял вашу базу данных.

Это может быть подвержено ошибкам при больших изменениях схемы, но это придется сделать сейчас.

0 голосов
/ 29 января 2013

Я думаю, вам нужна функция миграции EFCF.

Самый простой способ не потерять свои данные при смене моделей - это включить автоматическую миграцию с допустимой потерей данных:

internal sealed class Configuration : DbMigrationsConfiguration<YourFancyDBContext>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = true;
        AutomaticMigrationDataLossAllowed = true;
    }

...

Database.SetInitializer(new MigrateDatabaseToLatestVersion<YourFancyDBContext, Configuration>());

На самом деле сначала нужно выполнить несколько шагов: http://msdn.microsoft.com/en-US/data/jj591621

...