Comments 22
А также надеюсь, что информации от первоисточника по данному вопросу очень мало, потому-что это как-бы бета-версия и с релизом Entity Framework 5.0, не придётся методом проб и ошибок искать правильный вариант использования.
Зря надеетесь. Информации вполне достаточно.
На вопрос про миграции не смогли ответить эксперты и докладчики Microsoft на конференции WebProfessionals. Если бы информация была бы столь доступна, я думаю ответили бы незамедлительно.
А так могу сказать, что везде почему-то предлагают выполнять Add-Migration/Update-Database и везде пропускается информация об инициализаторе, наследованом от
А так могу сказать, что везде почему-то предлагают выполнять Add-Migration/Update-Database и везде пропускается информация об инициализаторе, наследованом от
MigrateDatabaseToLatestVersion
, без которого автомиграции не выполняются.Кстати, если есть ссылка, по которой всё это объясняется (без консольных команд Add-Migration/Update-Database), буду рад её увидеть.
romiller.com/2012/02/09/running-scripting-migrations-from-code/
А про MigrateDatabaseToLatestVersion написано вот тут: blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx, в комментах (откуда, кстати, и первая ссылка).
А про MigrateDatabaseToLatestVersion написано вот тут: blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx, в комментах (откуда, кстати, и первая ссылка).
Посовещавшись, решили использовать Entity Framework Code First, т.к. в перспективе возможна смена СУБД, а с этим вариантом нам нужно будет просто сменить строку соединения
какие еще варианты рассматривали?
полезный фрэймворк для миграции — FluentMigrator
NHibernate и eXpress Persistent Objects (XPO). О миграциях тогда не задумывались, нужно было просто, чтобы была возможность пересесть на другую СУБД.
какое ограничение у NHibernate при переходе на другую СУБД?
Да собственно никаких, само использование ORM не понравилось (ISession, DeattachedCriteria), показалось лишних действий больше при использовании. Смотрели очень быстро, на раздумья 2 часа было:)
Посмотрел мельком FluentMigrator, очень похож в использовании на EntityFramework Migrations. Есть принципиальные преимущества?
«Всё вроде замечательно, у кого базы нет она создаться»
Вообще-то, инициализатор DropCreateDatabaseIfModelChanges делает ровно то, что написано в названии — дропает БД при изменениях модели. Правда же, очень полезное поведение?
Вообще-то, инициализатор DropCreateDatabaseIfModelChanges делает ровно то, что написано в названии — дропает БД при изменениях модели. Правда же, очень полезное поведение?
Когда делаешь проект один и тестовых данных достаточно (и не предполагается поддержка/изменение), то и DropCreateAlways сойдёт. К сожалению, такое бывает очень редко и в таком случае DropCreateDatabaseIfModelChanges действительно бесполезен, более того может навредить, если вовремя не сделать бэкап.
Извиняюсь за оффтоп, но я бы «отрефакторил» имя класса :)
Не то чтобы я против nhiber'а, но почему-то по старинке все еще пишу на нем. Хотя уже вроде даже миграции есть.
Рекомендую заинтересованным посмотреть Entity Framework Code First Migrations, довольно подробно она рассказывает, видео совсем короткое, после просмотра я сразу начал искать книжку данного автора, которая приятно меня удивила.
Именно поэтому я выбираю ADO.NET для уверенности и полном контроле на работой с БД, потому что БД это самое«узкое место» в любом практически приложении. Однако, когда надо сделать что-то по-быстрому, то CodeFirst в помощь. Более того надеюсь в будущем EF станет действительно революционном прорывом по всем показателям, что сможет заменить ADO.NET в полном объеме.
Sign up to leave a comment.
Автоматическая миграция БД в Entity Framework