使用Entity Framework 4.3迁移而无需依赖于实际数据库

Question

EF migrations看起来很酷，但实际上有太多"魔法"在发生，而且很少有解释。 我只想设置迁移点并获取DDL脚本-无论是从一个迁移到另一个的“差异”脚本还是整个创建DDL脚本。

问题在于所有迁移命令似乎都依赖于实际存在的数据库来执行我不感兴趣的一堆东西。 是否有一种方式可以绕过所有这些内容，只是使用迁移生成脚本？

- w.brian

---

我完全同意你关于迁移（过度）设计的观点。如果我可以在没有数据库的情况下完成除了Update-Database之外的每一步，整个概念在团队环境中的效果会更好。 - Scott Stafford

Answer 1

这是昨天讨论的。迁移命令取决于您的工作数据库，因为它们与__MigrationHistory表交互以获取实际状态并正确计算需要进行的更改。

如果您只需要创建脚本，可以使用Update-Database和其他参数来完成：

为整个数据库创建脚本：

Update-Database -Script -SourceMigration:$InitialDatabase 

创建脚本以从迁移A升级到迁移B：

Update-Database -Script -SourceMigration:"A" -TargetMigration:"B"

- Ladislav Mrnka

---

很不幸，我无法运行第二个示例，因为创建第二个迁移失败，提示我有未完成的显式迁移。真的非常令人沮丧，他们应该提供一个选择退出他们试图执行的“魔法”的选项。 - w.brian

我并没有说迁移不需要数据库。在当前版本的迁移中，数据库是核心要求。你永远不可能有超过一个未应用于你的数据库的迁移。如果你不喜欢这样，你应该自己处理数据库升级 - 例如使用VS数据库项目。 - Ladislav Mrnka

显然这取决于数据库，我的观点是，如果我明确设置迁移点并指定从中脚本化的迁移点，则完全没有必要使用它。仅仅告诉我不要使用它既显而易见又有点刻薄，因为它不符合我的要求。 - w.brian

EF简单地采用了以数据库为中心的方法，以避免对数据库造成意外损害。原因在于自动迁移的存在，因为您的代码不包含有关已应用自动迁移的存在的信息，直到它查询数据库。事实上，您目前设置的AutomaticMigrationEnabled为false是不够的，因为您可能刚刚几分钟前更改了它。这样行为更加确定和安全。无论如何，您可以在Data UserVoice上提出更改建议。 - Ladislav Mrnka

这真的不是一个好借口，没有能力覆盖此行为。难道我们要自己编写迁移脚本，仅因为我们无法明确地选择退出此验证吗？应该有一种开关让我们知道我们在做什么并退出！:( https://dev59.com/lWXWa4cB1Zd3GeqPMmmN - Danny Tuppeny