尝试自学EF Code First，并且已经按照我现在想要的方式扩展了初始数据库创建设置，并且最初创建了数据库，但是试图弄清楚如何最好地处理和管理未来的更新a数据库，仍然可以创建新数据库。
我想出了一个我没有在网上找到任何好的例子或建议的场景。我想要一个用户可以创建新数据库的应用程序，该数据库基于当时代码中的POCO对象基于现有模型创建新数据库。正如我所说，到目前为止，这对我来说很好。稍后，程序更新出现，并通过程序集中的迁移对象，它知道要执行的操作并使用DbMigrator.Update（）方法使用EF Code First迁移更新数据库。到目前为止还不错，至少对于该程序的初始版本而言。
现在，稍后，在更新的版本中，他们想要出于任何原因创建一个新的数据库。所以它们基于当时代码中的当前模型，并且工作正常。但是，在程序集中此点之前还有其他迁移根本不需要运行，因为模型已经有任何可能需要设置并准备好的更改，但新创建的迁移表不会知道他们没有，至少就我所知。我不希望它们运行，但我希望将来的任何更新都应用于以后需要它们的任何数据库。
我的想法，从我到目前为止所读到的，我需要创建额外的逻辑来跟踪代码中的最新数据库迁移（使用某种时间戳属性进行各种迁移以确定顺序）创建并以某种方式告诉它不要在该日期/版本之前实际执行任何迁移更新，但EF迁移逻辑仍将使用告知其已运行特定迁移的信息更新__MigrationHistory表。我想我会通过反射手动执行此操作以获取迁移对象并通过在update方法中指定迁移对象名称来按顺序运行它们，但要进行一些检查以防止在初始化期间实际运行数据库更改。然后，当代码更新后稍后弹出任何新的迁移时，较旧的迁移将不会运行，因为它们已经在__MigrationHistory表中，但DbMigrator.Update方法仍将运行表中缺少的任何较新的迁移。
在我花了很多时间来弄清楚这个逻辑之前，我想确保文档中没有任何内容，或者说我完全忽视或错过了管道中的内容已经内置和/或获得更好关于处理这种情况的最佳方法的一些输入。在我看来，这似乎是一个相当常见的场景，但我没有看到使用基本EF逻辑处理它的好方法。
答案 0 :(得分：2)
你不应该担心这些......如果你只是总是使用DbMigrator.Update（），那么迁移将负责跟踪哪些迁移已经应用，哪些迁移没有。这仍然适用于您在第三段中提到的场景，您在项目中有许多迁移，但是您想创建一个新数据库，只需调用DbMigrator.Update（），它将使用您的迁移和记录创建数据库它们已被应用的事实。
〜罗文