DevExpress XPO vs NHibernate vs Entity Framework: проблема обновления базы данных

я не могу комментировать другие ORM, но я использовал DevExpress XPO для корпоративного казначейства с 2007 года. Схема немного меняется с каждым выпуском, но также были некоторые большие изменения схемы на протяжении многих лет. Несколько расширенная версия механизма обновления XPO по умолчанию удобно обслуживала все изменения.

есть хорошая основная информация здесь об обновлении XPO приложения.

• DevExpress предоставляет инструмент DBUpdater, чтобы помочь вам с задачей обновления производственных сред. Вы можете расширить этот инструмент, чтобы удовлетворить дополнительные требования. В моем приложении мы добавили некоторые опции для ведения журнала, предварительного просмотра с откатом и т. д.

• каждый модуль имеет виртуальный UpdateDatabaseBeforeSchemaUpdate() и UpdateDatabaseAfterSchemaUpdate() методы. Вы можете значительно контролировать процесс обновления внутри эти.

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

например, скажем MyNewField добавлено MyEntity класс XPO в версии 2.0 вашего приложения. Допустим, по умолчанию для существующих записей должно быть значение 3. Центр будет заниматься созданием новый столбец, но существующие записи будут иметь значение NULL. (Если вы укажете значение по умолчанию в классе XPO, оно будет относиться только к новым записям). Чтобы исправить значение для существующих записей, вы должны добавить что-то вроде следующего к переопределенному модулю сущности UpdateDatabaseAfterSchemaUpdate():

public override void UpdateDatabaseAfterUpdateSchema()
{
    base.UpdateDatabaseAfterUpdateSchema();
    if (CurrentDBVersion < new Version(2, 0, 0, 0))
        ObjectSpace.GetSession().ExecuteNonQuery(
            "UPDATE [MyEntity] SET [MyNewField] = 3 WHERE [MyNewField] IS NULL");
}

(вы также можете использовать ObjectSpace.GetObjects<MyEntity>() и a foreach если вы предпочитаете избегать прямого SQL.)

в более экстремальный пример разбиения таблицы на две части, вы можете использовать тот же метод, но вы будет переопределять UpdateDatabaseBeforeUpdateSchema() вместо этого запустите SQL для разделения таблицы, пусть XPO выполняет любые другие обновления схемы и, при необходимости, заполняет любые значения по умолчанию в UpdateDatabaseAfterUpdateSchema().

вы обнаружите, что сталкиваетесь с проблемами ограничений, например, нарушениями внешнего ключа, поэтому вам может потребоваться написать некоторые общие процедуры, такие как DropAllForeignKeyConstraints() в рамках UpdateDatabaseBeforeUpdateSchema(). Иногда вы обнаруживаете, что XPO уже что-то предоставляет, иногда нет. Отсутствующие ограничения и индексы будут восстановлены в обновлении схемы. (По моему опыту, переключение первичного ключа таблицы основных данных оказалось самой сложной процедурой обновления, чтобы получить право.)

по умолчанию все вызовы происходят в транзакции SQL, поэтому, если что-то не удается, все должно откатиться.

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

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

мы имеем дело с крупными международными компаниями и банками. Клиенты вполне довольны результатом. В ситуациях, когда DBA корпорации необходимо подписать изменения, они, похоже, не возражают иметь инструмент командной строки для обновления, а не сценарий.