如何构建兼顾EF4类库与EF7 .NET Core类库的项目架构

云上老周

2026-7-12

可行的架构方案：避免.NET Framework与.NET Core数据层代码重复

针对你既要保留现有.NET 4.8 WebForms/Data项目，又要新建.NET Core项目且避免数据层LINQ代码重复的需求，以下是几个落地性较强的方案：

1. 提取共享逻辑到.NET Standard类库

核心思路：将与ORM无关的领域模型（POCO实体）、业务规则、通用LINQ查询逻辑，抽离到一个**.NET Standard 2.0**类库中。.NET 4.8和.NET 6都原生支持这个版本，能保证双向兼容。
具体做法：
- 在Standard类库中定义纯POCO实体，比如：
```
public class User 
{ 
    public int Id { get; set; } 
    public bool IsActive { get; set; } 
    public DateTime LastLogin { get; set; }
}
```
- 封装通用LINQ查询为静态方法或扩展方法，比如：
```
public static class UserQueries
{
    public static IQueryable<User> GetActiveUsers(IQueryable<User> userQuery)
    {
        return userQuery.Where(u => u.IsActive && u.LastLogin > DateTime.Now.AddMonths(-6));
    }
}
```
- 原Data类库（EF4）和新DataCore类库（EF Core）仅保留各自的EF上下文、数据库配置、ORM专属操作，查询时直接调用Standard类库中的方法——Data类库中用ObjectSet<User>作为查询源，DataCore中用DbSet<User>替代即可。
优势：实现业务逻辑与LINQ查询的100%复用，对现有项目改动极小，仅需添加类库引用。
注意事项：禁止在Standard类库中引入任何EF4或EF Core的专属API，只依赖IQueryable和LINQ标准方法，确保跨ORM兼容。

核心思路：定义一套与ORM无关的Repository接口，放在.NET Standard类库中，让Data和DataCore分别基于EF4和EF Core实现这些接口，共享业务逻辑的抽象定义。
具体做法：
- 在Standard类库中定义通用和专属Repository接口，比如：
```
public interface IUserRepository
{
    IQueryable<User> GetAll();
    User GetById(int id);
    IQueryable<User> GetActiveUsers();
    void Add(User user);
    void SaveChanges();
}
```
- 共享的查询逻辑封装在静态辅助类中（.NET Standard 2.0不支持接口默认方法），两个实现类直接调用；或者在接口中定义抽象方法，实现类中复用同一套LINQ逻辑。
- WebForms项目依赖Standard类库的接口，注入Data类库的实现；ASP.NET Core项目同样依赖接口，注入DataCore类库的实现。
优势：上层应用与具体ORM解耦，后续切换ORM或扩展新数据源更灵活；数据层的差异被封装在实现类内部，业务查询逻辑统一。
注意事项：接口设计要贴合业务需求，避免过度抽象；现有Data项目的代码需要逐步重构迁移到Repository接口，适合分阶段改造。

核心思路：针对规整的CRUD和通用查询，用代码生成工具（T4模板、Roslyn代码生成器）从共享的元数据（比如Standard类库中的实体定义）自动生成Data和DataCore中的查询方法。
具体做法：
- 以Standard类库中的POCO实体为元数据，编写T4模板，读取实体属性和业务规则，自动生成EF4的ObjectSet操作方法和EF Core的DbSet操作方法。
- 对于复杂的自定义查询，可以在生成代码中预留扩展点，手动添加复用的LINQ逻辑。
优势：避免手动复制粘贴代码，保证两个数据层的查询逻辑完全一致；适合查询逻辑标准化、变化频率低的场景。
注意事项：需要维护代码生成模板，复杂的个性化查询难以通过生成器覆盖，仍需结合前两种方案补充。

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