Внесение изменений в модель предметной области с использованием сначала кода (ORM) в процессе производства

Question

Несмотря на то, что code-first отлично подходит для развертывания, а в процессе разработки я не вижу, как можно протолкнуть изменения, внесенные в вашу модель домена, в коде первым способом после запуска в производство.

Что мне делать с данными, собранными в то время, когда мы работали?

Должен ли я вручную переносить данные из схемы Версии A в схему Версии B. Нужно ли кодировать схему, чтобы предотвратить критические изменения? Должен ли я попрощаться с кодом первым после первоначального развертывания и переключиться на базу данных первым?

Чего мне не хватает?

Answer 1

Как уже упоминалось в комментарии @Henkie, EF Data Migrations пытается решить именно ту проблему, которую вы описываете.

У меня есть приложение, использующее EF с первым кодом в производстве, и сейчас мы создалинебольшая стратегия обновления схемы вдоль стороны EF.У нас есть таблица, которая понимает, в какой версии находится база данных, и каталог запускаемых сценариев sql (перенос данных, изменение схемы и увеличение таблицы версий).

ссылки:

1. На основе кода

2. Автоматически

Надеюсь, это поможет.

Answer 2

с EF 4.3.вам нужно использовать миграции, и вы можете сделать это с существующей базой данных.

Это отличный пост в блоге о том, о чем вы говорите: Использование EF 4.3 Code Первые миграции с существующей базой данных от Джули Лерман.

Я также веду блог об этом прямо сейчас: Использование Entity Framework Code First с существующей базой данных .

Answer 3

Во-первых, отказ от ответственности, у меня нет большого опыта работы с EF, и я бы предположил, что в этом отношении он похож на nHibernate.Я ответил на аналогичный вопрос здесь .Суть в том, что EF и NHibernate - это просто рамки ORM.Они имеют глубокие знания вашего домена, но только в его текущем состоянии, они не знают истории.ORM может генерировать схему базы данных, но эта функция полезна только для первоначального развертывания и тестирования интеграции.Вы не можете полагаться на него в производственном приложении, которое развивается и нуждается в обновлении (как для схемы, так и для данных).

По моему опыту, нет волшебного инструмента, который будет писать сценарии обновления, они должны быть написаны вручную или, по крайней мере, проверены разработчиком.Инструменты могут предоставить вам среду для выполнения этих сценариев, например RoundhouseE .У Скотта Аллена есть превосходная серия о подходе «только вперед, один раз».