Простое решение для автоматизации контроля за состоянием базы данных с использованием EF Core

[avter]

>Их надо было накатить на базу и по очереди,

>берем все, то что находится в поддиректории \Sql

где тут по очереди, брат?

[sejkeee]

Привет! Спасибо за вопрос. В статье фраза "по очереди" используется как речевой оборот. Действительно, зачастую случается так, что скрипты необходимо применять по определенному порядку. Описанное решение легко можно расширить)

[baaaa]

А почему не используете какие-нибудь Flyway?

[Dansoid]

Так, что же я сделал у нас... Я научил EF Core сохранять старые процедуры прямо в snapshot файлах. Это не сложно, для модели можно навесить атрибуты во время OnModelCreating, обвесив это красивыми расширениями. Это может выглядеть так modelBuilder.HasStoredProcedure("Some", @"CREATE OR ALTER Some ....").

Что же дальше, создаем свой IMigrationsModelDiffer - для каждого провайдера своя реализация и надо от нее наследоваться. При правильной ее регистрации и реализации можно запросто получить автоматическую генерацию миграций вверх и вниз. Сравниваются две модели старая и новая - в старой нет - создаем процедуру, в новой нет - скрипт на удаление, поменялась - делаем обновление.

Теперь если надо изменить процедуру, меняем ее код прямо в C# файле + Add-Migration ProcedureChanged и миграции создаются.

Бенефит ту так же в том что процедуры могут генерироваться динамически используя структуру таблиц, и вот если кто-то изменит определение таблицы, тут же генерируется новая миграция вместе с кодом отката.

Используя этот подход можно и представления включать и много чего друго, скажем так: команда расслабилась, все работает автоматически и координируется в одном месте. Не надо ресурсы сохранять, держать рядом папочку со скриптами и так далее...

Ну и немаловажный бенефит context.Database.EnsureCreated() - запускает все вместе, создает таблицы и процедуры одним скопом, при чем без явных миграционных файлов.