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

Question

我一直是一个面向数据库的程序员，所以直到今天，我一直使用数据库驱动的方法来编程，我对 T-SQL 和 [=49 很有信心=] 服务器.

我正在努力思考 Entity Framework6 code-first 方法 - 坦率地说 - 我正在努力。

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

我现在想做的是探索如何处理正在进行的数据库升级——包括模式和 "static"（预填充）查找数据。我的第一个抱怨是，从数据库逆向工程的实体正在配置 Fluent API，而创建新的 tables 对我来说似乎更自然，我想创建为带有数据注释的 C# class。 "mixing" 这两种方法有什么问题吗？或者我可以告诉逆向工程步骤只使用数据注释属性而不是 Fluent API 吗？

我的第二个甚至更大的抱怨：我正在尝试创建不错的小型迁移 - 为我要添加的每组功能分别创建一个迁移（例如，一个新的 table、一个新的索引、一些新专栏等） - 但似乎我不能超过一个 "pending" 迁移......当我有一个时，我进一步修改我的模型 classes，然后我尝试使用 add-migration (name of 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

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

假设我有一个 class Widget:

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

和数据库中匹配的 table Widgets：

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

现在我决定添加一个新的属性 Size 到我的 class.

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

当我创建迁移时，生成器查看我的模型，将其与数据库进行比较，发现我的 Widget 模型现在有一个 Size 属性而相应的 table 没有 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 命令，所以我的基线数据库架构仍然相同。现在我决定添加另一个属性 Color 到 Widget.

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

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

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

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

更改模型
生成迁移
更新数据库以建立新基线
重复

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

Update-Database –TargetMigration PreviousMigrationName

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

希望这有助于解决问题。

Answer 2

Is there any problems / issues with "mixing" those two approaches?

不，混合使用没有问题。
与数据注释相比，使用流畅的配置可以做更多的事情。
构建迁移脚本时，Fluent 配置会覆盖数据注释。
您可以使用数据注释动态生成 DTO 和 front-end/UI 约束 - 节省大量代码。
Fluent API 具有 class EntityTypeConfiguration，它允许您动态创建对象的域（在 DDD 意义上）并存储它们 - 大大加快了 DbContext 的工作速度。

I cannot have more than a single "pending" migration

并非 100% 正确。（可能是 50%，但这不是一个亮点）
是的，DbMigrator 在生成 Db 时会将您的模型 "hash" 与数据库模型 "hash" 进行比较 - 因此它会在您进行新的小型迁移之前阻止您。但这并不是认为您不能进行小的迁移步骤的理由。我一直只做一些小的迁移步骤。
当您开发应用程序并使用本地数据库时，您会在开发功能时逐步应用小迁移。最后，您将所有小迁移部署到 staging/production 一个 dll 中，其中包含所有新功能 - 并且它们会被一一应用。

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

Trying out EF code-first and migrations - stumbling blocks

c#

sql-server

code-first

entity-framework-migrations

entity-framework-6