实体框架迁移可以做什么 FluentMigrator 不能？答案

【问题标题】：What can Entity Framework Migrations do that FluentMigrator cannot?实体框架迁移可以做什么 FluentMigrator 不能？
【发布时间】：2013-08-26 16:59:24
【问题描述】：

我目前有几个数据库正在使用 FluentMigrator，我很想知道实体框架迁移的比较。

EF Migrations 能否在迁移中播种数据并根据 FluentMigrator 等环境有选择地运行迁移脚本，可以使用标签和配置文件？

我已经在使用 EF Database First 作为我的应用程序的 ORM，并且我想我在某处读到过，非 Code First EF 现在也支持 EF 迁移，但我的团队一直在考虑重构为 Code First无论如何，因为 Database First 方法的一些限制。那么，在使用代码优先方法时，EF 迁移是否比使用另一个第三方迁移框架更有意义？

【问题讨论】：

嗯，首先，FM 不能自动生成迁移。也就是说，它不会扫描数据库，确定发生了什么变化，并根据差异创建脚本。 EFM 就是这样做的。
三年后的现在，我很想知道您是否尝试过转换，以及您的经历。似乎大多数使用迁移的人都使用其中一个，并且对另一个没有真正的看法。

标签： .net asp.net-mvc entity-framework ef-code-first fluent-migrator

【解决方案1】：

我对 FluentMigrator 没有任何经验，但在简要浏览文档后，您似乎必须手动创建迁移？

每当您的模型发生更改并且应用程序运行时，EF 都会提示您进行迁移。这使它有点容易，但同时也很烦人。启用迁移后，对模型进行的任何涉及数据库更改的更改都需要迁移。您可以修改迁移，它是自动生成的。只看“向下”版本...我遇到了问题。

代码优先是非常无缝的。甚至可以处理更复杂的对象模型，例如子类。您甚至可以指定如何生成表（每种类型的表、基表和每种类型的表，或者单个表和类型键）。

话虽如此，如果您总是要生成 c# 代码来更新您的数据库，我会选择 EF 的内置迁移。他们为您完成大部分工作。

【讨论】：

我看不出两者之间的真正区别是什么；不知道我是否应该在我的情况下使用一个而不是另一个

【解决方案2】：

Entity Framework 自动生成迁移文件并支持 LINQ-to-SQL。相比之下，FluentMigrations 仅编写迁移脚本，不会自动生成迁移文件。 FluentMigrations 比 Entity Framework Code-First 早几年开发。

【讨论】：