同一项目中EF Core与EF 6.x兼容的迁移问题及实践咨询

当然有不少生产环境里同时跑EF6和EF Core的案例，这种方案完全是可行的，至于价值得看你的具体需求来判断，下面给你拆解下：

• 渐进式迁移，降低重构风险：你的项目是从EF4逐步升级到EF6的，现在引入AspNet Core+EF Core不用一次性推翻原有稳定的EF6代码。先把新的AspNet Core站点用EF Core+Identity搞定，后续可以根据业务优先级慢慢把旧的EF6模块迁移过来，避免一次性重构带来的业务中断风险。
• 充分利用EF Core的原生优势：EF Core和AspNet Core的集成更原生，尤其是Identity模块的适配更顺畅；同时EF Core支持更多数据库类型、更好的查询性能、更灵活的依赖注入配置，新业务模块用这套组合会更顺手。
• 上下文隔离，互不干扰：你已经把Core.Identity的上下文单独配置，这种隔离方式能让EF6和EF Core各自处理自己的业务域，不会因为ORM版本差异搅乱原有稳定的EF6迁移和数据操作逻辑。

• 严格区分两套迁移系统：EF6和EF Core的迁移是完全独立的，千万别搞混：
  • EF6的迁移还是用原来的Add-Migration、Update-Database命令，操作时要在Package Manager Console里选对EF6的项目；
  • EF Core的迁移要用dotnet ef migrations add、dotnet ef database update命令，指定对应的Core项目和Identity上下文。
• 共享数据库的映射一致性：如果两个ORM操作同一个数据库，对于共享的表（比如可能和Identity关联的用户表），要确保实体映射的字段、约束完全一致，避免出现数据结构不兼容的问题。
• DI配置避免冲突：EF6本身不支持AspNet Core的依赖注入原生集成，在Core项目里注入EF6上下文时，要单独处理（比如用工厂模式包装，或者手动配置生命周期），别和EF Core的AddDbContext配置混在一起。
• 日志调试分开处理：两套ORM的日志系统逻辑不同，排查问题时要分别查看EF6和EF Core的日志输出，避免混淆排查方向。

我接触过不少企业级项目都是这么做的：比如一个传统ERP项目，原有库存、采购模块用EF6稳定运行，新开发的移动端后台、用户权限中心（基于AspNet Core Identity）用EF Core，两者操作同一个数据库，上线后稳定运行了两年多，期间逐步把旧模块的EF6代码迁移到EF Core，实现了平滑过渡。

内容的提问来源于stack exchange，提问作者JCircio