现有数据库和新数据库的EntityFramework 6迁移？

Question

在我们的软件中，我们有一个现有数据库的客户群。数据库目前是通过EntitySpaces访问的，但是我们希望切换到EntityFramework (v6)，因为EntitySpaces不再受支持。我们还想利用迁移特性。自动迁移是禁用的，因为我们只希望允许数据库迁移到管理用户。

我们从现有的数据库中生成EF模型。所有这些都运行得很好，但真正的问题是，在编程上区分与模型匹配但尚未转换为EF (缺失MigrationsHistory表)的现有数据库和空/新数据库。转换现有数据库可以很好地处理空迁移，但是对于新数据库，我们还需要包含完整模型的迁移。在迁移链中进行初始迁移总是与现有数据库发生冲突。当然，我们可以使用外部SQL脚本或ADO命令创建一个解决方案，创建和填充MigrationsHistory表。但这是我们想要避免的，因为我们的一些客户端使用MsSql数据库，有些使用Oracle。所以我们非常希望保持EF提供的抽象层。

有没有一种方法可以让EF通过基于代码的迁移来处理现有的和新的数据库，而不回到非EF的解决方案？

Answer 1

我最初的建议是捕获CreateTable引发的异常，但结果发现这是在不同的地方执行的，因此不能将其困在异常中。

如果初始数据库不存在，则使用Seed方法创建初始数据库是最简单的方法。做这个..。

1. 从空白数据库开始，添加初始创建迁移并获取生成的SQL。 添加-迁移InitialCreate更新-数据库-Script
2. 保存这个脚本。您可以将其添加到资源、静态文件中，甚至可以将其保留在代码中，如果您真的需要的话，这取决于您。
3. 从InitialCreate迁移中删除所有代码(留给它一个空白的Up()和Down()函数)。这将允许运行空迁移，从而生成MigrationHistory表。
4. 在迁移配置类中，可以使用context.Database.SqlQuery和context.Database.ExecuteSqlCommand动态查询和执行SQL。测试主表是否存在，如果不存在，则执行上面生成的脚本。

这不是很整洁，但实现起来很简单。很好地测试它，因为种子方法在每次迁移之后运行，而不仅仅是初始迁移。这就是为什么您需要在做任何事情之前测试主表的存在。

更复杂的方法是编写用于迁移的"CreateTableIfNotExists“方法，但这将涉及使用反射调用DbMigration类中的内部方法。