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

Question

我一直都是面向数据库的程序员，所以直到今天，我一直使用数据库驱动的编程方法，我对T- SQL和SQL Server。

我想换我的头周围的实体框架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我正在添加？

好像是一个BIG缺点！我宁愿创建我的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表中）。对于尚未应用的代码中的任何迁移，它将全部运行它们，以便使数据库保持最新状态。

希望这有助于澄清事情。

Answer 2

有没有用“混合”这两个方法的任何问题/问题？

1. 不，混合它们没有问题。
2. 您可以使用流畅的配置比使用数据注释做得更多。构建迁移脚本时
3. 流利的配置覆盖数据注解。
4. 您可以使用数据标注动态生成的DTO和前端/ UI约束 - 节省了大量的代码。
5. 流利的API有类EntityTypeConfiguration，它允许你创建一个对象域（DDD中的意义上的）动态，并将其储存 - 用的DbContext加快工作了很多。

我不能有比一个单一的 “未决” 迁移

1. 不是100％真更多。 （也许50％，但是这不是一个搅局者）
2. 是的，DbMigrator模型“哈希”比较数据库模型“哈希”，当它生成数据库 - 因此它的块时，你让你的新的小型迁移之前。但这不是认为你不能进行小型迁移步骤的理由。我一直只做很小的迁移步骤。
3. 当你开发一个应用程序，你用你的本地数据库您可以通过一个应用小迁移一个为您开发功能 - 逐步显现。最后，您将部署所有新的功能，将所有小型迁移集成到一个dll中，然后逐个应用它们。