尝试首先自学 EF 代码，并且已经按照我现在想要的方式扩展了初始数据库创建设置以及数据库的初始创建，但试图弄清楚如何最好地处理和管理数据库的未来更新，但仍然与创建新数据库一起工作。
我想出了一个场景，我没有在网上找到任何好的例子或建议。我想要一个用户可以创建新数据库的应用程序，它根据当时代码中的POCO对象基于现有模型创建一个新数据库。正如我所说，到目前为止，这对我来说很好。稍后，程序更新出现了，通过程序集中的迁移对象，它知道要做什么，并使用 DbMigrator.Update() 方法使用 EF Code First 迁移更新数据库。到目前为止一切顺利，至少对于程序的初始版本而言。
现在，稍后，在更新的版本中，无论出于何种原因，他们都希望创建一个新数据库。所以他们是根据当时代码中的当前模型来做的，而且效果很好。但是，在装配之前的这些其他迁移根本不需要运行，因为模型已经有任何可能需要设置并准备就绪的更改，但新创建的迁移表没有至少据我所知，他们不知道。我不希望它们运行，但我希望将来的任何更新都应用于以后需要它们的任何数据库。
我的想法，从我目前所读的内容来看，我需要创建额外的逻辑来跟踪代码中最新的数据库迁移（使用某种时间戳属性来确定各种迁移的顺序），并且以某种方式告诉它不要实际执行该日期/版本之前的任何迁移更新，但 EF 迁移逻辑仍将使用告诉它特定迁移已运行的信息更新 __MigrationHistory 表。我想我将通过反射手动执行此操作，以获取迁移对象并通过在更新方法中指定迁移对象名称来按顺序运行它们，但有一些检查以防止在初始化期间实际运行数据库更改。然后，当代码更新后出现任何新的迁移时，旧的迁移将不会
在我花了很多时间弄清楚这个逻辑之前，我想确保文档中没有任何东西，或者我完全忽略或错过的管道中没有任何东西可以更好地处理这个已经内置和/或获得一些输入处理这种情况的最佳方法。在我看来，这似乎是一个相当普遍的场景，但我看不到使用基本 EF 逻辑处理它的好方法。