c# - 尝试 EF 代码优先和迁移 - 绊脚石

Question

我一直是一个面向数据库的程序员，所以直到今天，我一直使用数据库驱动的方法进行编程，我对 T-SQL 和 SQL Server 非常有信心。

我正在尝试围绕 Entity Framework 6 code-first 方法进行思考 - 坦率地说 - 我正在努力。

我有一个现有的数据库 - 所以我执行了 Add New Item > ADO.NET Entity Data Model > Code-First from Database 并且我得到了一堆代表我现有数据库的 C# 类。到目前为止一切顺利。

我现在想做的是探索如何处理正在进行的数据库升级 - 无论是模式还是“静态”(预填充)查找数据。我的第一个提示是，从数据库反向工程的实体正在使用 Fluent API 配置，而创建新表似乎更自然，我想将其创建为带有数据注释的 C# 类。 “混合”这两种方法有什么问题吗？或者我可以告诉逆向工程步骤只使用数据注释属性而不是完全使用 Fluent API 吗？

我的第二个也是更大的提示:我正在尝试创建不错的小型迁移 - 针对我要添加的每组功能(例如，一个新表、一个新索引、一些新列等)分别进行一个迁移。 ) - 但似乎我只能有一个“待定”迁移......当我有一个时，我进一步修改了我的模型类，然后我尝试使用 add-migration 进行第二次迁移(迁移名称)，欢迎我:

Unable to generate an explicit migration because the following explicit migrations are pending: [201510061539107_CreateTableMdsForecast]. Apply the pending explicit migrations before attempting to generate a new explicit migration.

说真的 ?!?!? 我不能有超过 一个，单个 待处理的迁移？？我需要运行 update-database 在我添加的每个微小迁移之后？

这似乎是一个相当大的缺点!我更愿意创建我的 10、20 个小型、紧凑、易于理解的迁移，然后然后一次性应用它们 - 没办法做到这一点!？!？这真的很难相信......有什么办法解决这个问题？？

Answer 1

的确，在开发期间您一次只能打开一个待处理的迁移。要了解原因，您必须了解迁移是如何生成的。生成器通过将数据库(架构)的当前状态与模型代码的当前状态进行比较来工作。然后它有效地创建了一个“脚本”(一个 C# 类)来更改数据库的模式以匹配模型。您不希望同时有多个待处理的脚本，否则脚本会相互冲突。让我们举一个简单的例子:

假设我有一个类 Widget:

class Widget
{
    public int Id { get; set; }
    public string Name { get; set; }
}

和数据库中的匹配表 Widgets:

Widgets
-------
Id (int, PK, not null)
Name (nvarchar(100), not null)

现在我决定向我的类添加一个新属性 Size。

class Widget
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Size { get; set; }  // added
}

当我创建迁移时，生成器查看我的模型，将其与数据库进行比较，发现我的 Widget 模型现在有一个 Size 属性，而相应的表没有 Size 列。所以最终的迁移看起来像这样:

public partial class AddSizeToWidget : DbMigration
{
    public override void Up()
    {
        AddColumn("dbo.Widgets", "Size", c => c.Int());
    }

    public override void Down()
    {
        DropColumn("dbo.Widgets", "Size");
    }
}

现在，假设允许在第一个迁移仍未决时创建第二个迁移。我还没有运行 Update-Database 命令，所以我的基线数据库架构仍然相同。现在我决定向 Widget 添加另一个属性 Color。

当我为此更改创建迁移时，生成器将我的模型与数据库的当前状态进行比较，发现我添加了两 列。所以它创建了相应的脚本:

public partial class AddColorToWidget : DbMigration
{
    public override void Up()
    {
        AddColumn("dbo.Widgets", "Size", c => c.Int());
        AddColumn("dbo.Widgets", "Color", c => c.Int());
    }
    ...
}

现在我有两个挂起的迁移，它们都将在最终运行时尝试向数据库添加一个 Size 列。显然，这是行不通的。所以这就是为什么一次只允许打开一个挂起的迁移。

因此，开发过程中的一般工作流程是:

1. 改变你的模式
2. 生成迁移
3. 更新数据库以建立新的基线
4. 重复

如果出错，可以使用Update-Database 命令的–TargetMigration 参数将数据库回滚到之前的迁移，然后删除错误的迁移(s) 从你的项目中生成一个新的。 (如果你真的愿意，你可以使用它作为将几个小迁移组合成一个更大块的方法，尽管我发现在实践中不值得付出努力)。

Update-Database –TargetMigration PreviousMigrationName

现在，当需要更新生产数据库时，您不必一次手动应用每个迁移。这就是迁移的美妙之处——只要您对数据库运行更新的代码，它们就会自动应用。在初始化期间，EF 查看目标数据库并检查迁移级别(这存储在特殊的 __MigrationHistory 表中，该表是在您启用数据库迁移时创建的)。对于您代码中尚未应用的任何迁移，它会按顺序运行它们，以使数据库保持最新。

希望这有助于解决问题。