Shocker.ProhVosttВсё верно. Все миграции писать ручками, завести служебную таблицу миграций (чтобы поддерживать схему БД), написать механизм миграций.А где смайлик?
А есть какая-нить ОРМ, которая поддерживает автоматическую генерацию миграций, помимо EF?

Зачем смайлик? :)

В текущей системе у нас миграции не просто автоматические, они полностью динамические, таблицы, связи, констрейты, индексы создаются на лету во время исполнения программы, аналитик описывает модели на DDL прям в приложении, это отражается в БД. Мы систему runtime-миграции написали сами, на EF мы бы ничего подобного даже близко не сделали никогда. Поэтому, я серьёзно. Собственные миграции, это айс :)

В общем, смотри сам. Попробуй пожить с EF :) Может сможешь как-то закостылить узкие места до лучших времён. У нас есть маленький проектик на EF Core, ничо, живёт.

hVosttаналитик описывает модели на DDL

*DML

Shocker.ProНу динамика - это отдельная песня, то понятно.
Но в статике-то хотелось больше сервиса, иначе полностью теряется преимущество CodeFirst и проще использовать DBFirst, чтобы не писать два раза одно и то же.

Я к тому, что авто-миграции, это конечно хорошо. Но чтоб от них действительно был прям офигенский профит, это надо каждый день вносить кучу изменений или фрилансить на студентов, ну или я не знаю что ещё. Обычно изменения модели не такие частые, чтобы это прям было таким камнем.

Да, удобно, но не более. За день-два можно написать неплохой механизм миграций для своего проекта. Ну и допиливать его по мере необходимости.

Shocker.Proи проще использовать DBFirst, чтобы не писать два раза одно и то же.

Ну, возможно... Я уже сто лет как не разрабатываю ПО через БД, это фигня какая-то ))

Petro123а аналитики пишут (РИСУЮТ) Модель в DDL.)))
Неувязочкасс)).

Ну зависит от степени автоматизации. В допотопных конторах пусть аналитики фигачат DDL ))