从 EF6 移植到 EF Core - 数据库作为事实来源
如果使用数据库作为事实来源，则升级主要涉及处理对生成的实体形状所做的任何更改。 迁移步骤包括：
- 选取一个时间点来为数据库建模。
- 确保 EF6 项目是最新的，并与数据库同步。
- 创建 EF Core 项目。
- 使用 基架工具 对数据库进行反向工程以编码。
- 验证 EF Core 生成的类是否与代码兼容。
- 对于例外情况，请修改生成的类并更新 模型配置 ，或者将代码调整为模型。
请注意，尽管 EF Core 目前为成功生成数据库副本所需的一切内容搭建了基架，但数据库优先方法不需要大部分代码。 此问题的修补程序在 问题 #10890 中进行了跟踪。 可以放心忽略（不需要）包括：序列、约束名称、非唯一索引和索引筛选器。
处理架构更改
当数据库是事实来源时，EF Core 会从数据库拉取架构信息，而不是通过迁移推送它。 典型的工作流是在数据库架构发生更改时重新运行反向工程步骤。 全面的测试套件对于此方法非常有用，因为你可以自动执行基架过程，并通过运行测试来验证更改。
有关处理模型差异的提示
出于各种原因，你可能希望 C# 域模型的形状不同于在反向工程中生成的模型。 在许多情况下，这意味着手动更新每次架构更改后自动生成的代码。 在重新生成代码时，防止额外工作的方法之一是为 DbContext 和相关实体使用分部类。 然后，可以将与数据库中未跟踪的业务逻辑和属性相关的代码保存在一组单独的类文件中，这些类文件不会被覆盖。
如果模型与生成的模型明显不同，但不经常更改，请考虑使用 存储库模式 作为适配器的一个选项。 存储库可以使用 EF Core 生成的类并发布所使用的自定义类。 这可以通过将更改隔离到存储库代码中来减少更改的影响，而无需在每次架构更改时执行应用程序范围的重构。
可能需要考虑备用工作流，并遵循类似于 混合方法的步骤。 指示特定表仅生成新类，而不是每次生成一组新的类。 可以“按原样”保留现有类，并直接添加或删除更改的属性。 然后，更新模型配置，以解决数据库映射到现有类的方式的任何更改。
自定义代码生成
EF Core 6 当前不支持自定义生成的代码。 有第三方解决方案（如 EF Core Power Tools ）可用。 有关精选社区工具和扩展的列表，请参阅： EF Core 工具和扩展。
最后，查看 EF6 和 EF Core 之间的差异的详细列表 ，以解决移植的剩余问题。