.NET Framework与.NET Core共享EntityFramework数据上下文的方案探讨

可行方案分析 #

1. 实体类迁移至.NET Standard 2.0类库实现共享 #

完全可行，这是低成本复用的优先方案：

• 新建一个.NET Standard 2.0类库，迁移原EF6项目中实体类（DbSet对应模型）、通用数据注解（如[Table]、[Column]）、枚举等纯模型代码。
• 原EF6的DAL项目引用该类库，修改原有DbContext，直接使用共享类库的实体定义。
• .NET 8的EF Core项目同样引用该类库，在新DbContext中复用这些实体。
• 注意：EF6与EF Core对部分注解的支持存在细微差异，需统一调整为两者兼容的写法（比如[MaxLength]是通用的，EF6专属特性需移除或替换）。

2. 是否需要维护两个数据上下文？ #

是的，但可通过共享实体大幅降低维护成本：

• 无需重写两套完整DAL逻辑，仅需分别维护EF6和EF Core的DbContext配置（如映射关系、连接字符串、全局查询过滤等）。
• 通用业务查询逻辑可抽离到.NET Standard类库，基于共享实体编写，让两个DAL项目直接调用，避免重复编码。

3. 其他替代方案 #

• 适配器层封装：将原EF6 DAL封装为Web API/WCF服务，.NET 8项目通过HTTP调用访问数据。此方案适合性能要求不高的场景，但会增加网络开销。
• 统一数据访问层（Dapper）：用Dapper替换EF作为中间数据访问层，实体类放在共享类库，编写通用CRUD方法，同时兼容.NET Framework和.NET 8，规避EF版本差异问题，适合简单数据操作场景，维护成本远低于两套EF上下文。
• 逐步升级原项目：若长期规划统一技术栈，可先将原.NET Framework项目逐步升级到.NET 6/8，再切换为EF Core。此方案成本最高，但能彻底消除版本差异问题。

4. Scaffold-DbContext的优化思路 #

你提到的维护成本高问题，可通过分层架构解决：

• 将自动生成的实体、DbContext放在单独类库，自定义查询逻辑、扩展方法放在另一类库并引用生成库，重新生成时不会覆盖自定义代码。
• 结合共享实体方案，不再自动生成实体，仅生成DbContext的配置部分，复用.NET Standard类库中的实体定义。

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