从 EF6 移植到 EF Core - 数据库作为事实源

如果使用数据库作为事实源，则升级将主要涉及处理对所生成实体的形状所做的任何更改。 迁移步骤包括：

1. 选取一个时间点来对数据库建模。
2. 确保你的 EF6 项目是最新的且与数据库同步。
3. 创建 EF Core 项目。
4. 使用基架工具将数据库反向工程为代码。
5. 验证 EF Core 生成的类是否与你的代码兼容。
6. 对于异常，请修改生成的类并更新模型配置，或者调整代码以适应模型。

请注意，尽管 EF Core 目前为成功生成数据库副本所需的一切内容搭建基架，但数据库优先方法并不需要很多代码。 问题 #10890 中跟踪了此问题的修补程序。 可因为不需要而安全忽略的内容包括：序列、约束名称、非唯一索引和索引筛选器。

处理架构更改

当数据库是事实源时，EF Core 会从数据库中拉取架构信息，而不是通过迁移推送该信息。 典型的工作流是，每当数据库架构发生更改时，都重新运行反向工程步骤。 全面的测试套件对于此方法非常有用，它让你能够自动执行基架过程，并通过运行测试来验证更改。

有关处理模型差异的提示

出于各种原因，你可能希望 C# 域模型的形状与反向工程中生成的模型不同。 在许多情况下，这意味着手动更新每次架构更改后自动生成的代码。 要在重新生成代码时避免额外的工作，一种方法是对 DbContext 和相关实体使用分部类。 然后，可以将与数据库中未跟踪的业务逻辑和属性相关的代码保留在单独的一组不会被覆盖的类文件中。

如果你的模型与生成的模型明显不同，但不会频繁更改，那么一种方法是使用存储库模式作为适配器。 存储库可以使用 EF Core 生成的类，并发布你使用的自定义类。 这可通过将更改隔离到存储库代码中来减少更改的影响，而不必在每次架构更改时执行应用程序范围的重构。

你可能需要考虑备用工作流，并执行与混合方法类似的步骤。 不是每次都生成一组新的类，而是指示特定表仅生成新类。 将现有类按“原样”保留，并直接添加或移除已更改的属性。 然后更新模型配置，来解决关于数据库如何映射到现有类的任何更改。

自定义代码生成

EF Core 6 目前不支持对生成的代码进行自定义。 有第三方解决方案可用，例如 EF Core Power Tools。 有关特色社区工具和扩展的列表，请参阅：EF Core 工具和扩展.。

最后，请查看 EF6 和 EF Core 之间的差异的详细列表，解决移植存在的任何遗留问题。