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

Question

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

我试图围绕Entity Framework 6 代码优先的方法 - 坦率地说 - 我正在努力.

我有一个现有的数据库 - 所以我做了一个Add New Item > ADO.NET Entity Data Model > Code-First from Database,我得到了一堆代表我现有数据库的C#类.到现在为止还挺好.

我现在要做的是探索如何处理正在进行的数据库升级 - 包括模式以及"静态"(预先填充的)查找数据.我的第一个抱怨是,从数据库进行逆向工程的实体正在使用Fluent API进行配置,而我似乎更自然地创建了我想要创建的具有数据注释的C#类的新表."混合"这两种方法是否有任何问题/问题？或者,我可以告诉逆向工程步骤只使用数据注释属性而不是Fluent API吗？

我的第二个甚至更大的抱怨:我正在尝试创建漂亮的小型迁移 - 每个我想要添加的功能集(例如新表,新索引,一些新列等) - 但是似乎我不能只有一个"挂起"的迁移......当我有一个,并且我进一步修改我的模型类,并且我尝试使用第二次迁移时add-migration (name of migration),我受到了欢迎:

无法生成显式迁移,因为以下显式迁移尚未处理:[201510061539107_CreateTableMdsForecast].在尝试生成新的显式迁移之前应用挂起的显式迁移.

说真的？!？!？我不能有多个,单个挂起的迁移？我需要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命令,所以我的基线数据库架构仍然是相同的.现在我决定到另一个属性添加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在最终运行时尝试向数据库添加一个列.显然,这是行不通的.这就是为什么一次只允许打开一个挂起的迁移的原因.

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

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

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

Update-Database –TargetMigration PreviousMigrationName

现在,当需要更新生产数据库时,您不必一次手动应用每个迁移.这就是迁移之美 - 只要您针对数据库运行更新的代码,它们就会自动应用.在初始化期间,EF查看目标数据库并检查迁移级别(这存储在__MigrationHistory您在数据库上启用迁移时创建的特殊表中).对于尚未应用的代码中的任何迁移,它将为您运行所有迁移,以使数据库保持最新状态.

希望这有助于澄清事情.