What can Entity Framework Migrations do that FluentMigrator cannot?
I have several databases currently using FluentMigrator and am curious to know how Entity Framework Migrations compare.
Can EF Migrations seed data in migrations and selectively run migration scripts based on environments like FluentMigrator can with tags and profiles?
I am already using EF Database First as the ORM to my application, and I think I read somewhere that EF Migrations are supported for non-Code First EF as well now, but my team has been thinking about refactoring to a Code First approach anyway because of some of the limitations with the Database First approach. So would EF Migrations just make more sense to use rather than have another 3rd party migration framework when going with a code first approach?
I don't have any experience with FluentMigrator but after a brief skim of the documentation, it looks like you have to create your migrations manually?
EF will prompt for a migration every time your model changes and the app is run. This makes it kind of easy, but annoying at the same time. Once you've turned on Migrations, any changes to your model that would involve a database change will require a migration. You can modify the migration tho, and it's auto generated. Just watch the "down" version... I've had issues.
Code first is pretty seamless tho. Even handles more complex object models like subclasses. You can even specify how the tables are generated (table for each type, base table and a table for each type, or single table and a type key).
All that to say, if you're gonna always generate c# code to update your database, I'd go with EF's built in migrations. They do most of the work for you.
链接地址: http://www.djcxy.com/p/62326.html上一篇: 数据库版本之间的数据迁移