注入DbContext调用查询与两类查询实现方案的利弊权衡问询

我已注入**跟踪（TrackingDbContext）和非跟踪（NoTrackingDbContext）**两种DbContext，当前通过扩展方法实现查询，示例代码如下：

扩展方法代码 #

public static class SkillsExtensions
{
    public static async Task<List<Skill>> AllSkills(this LouisHoweDbContext context)
    {
        return await context.Skills.OrderBy(s => s.Name).ToListAsync();
    }
}

Razor页面代码 #

[Inject]
private NoTrackingDbContext NoTrackingDbContext { get; set; } = null!;

private List<Skill>? _allSkills;

protected override async Task OnInitializedAsync()
{
    _allSkills = await NoTrackingDbContext.AllSkills();
    await base.OnInitializedAsync();
}

DbContext服务注册方式：

builder.Services.AddDbContextFactory<TrackingDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("LouisHoweDb"))
        .EnableSensitiveDataLogging());
builder.Services.AddDbContextFactory<NoTrackingDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("LouisHoweDb"))
        .EnableSensitiveDataLogging());

我考虑通过两种服务方式实现各类查询方法，核心要求是每个查询都能被任意一种DbContext调用，且大部分查询需根据场景选择合适的上下文执行。以下是两种方案的具体利弊：

优点 #

• 调用简洁：直接通过DbContext实例调用方法，和现有扩展方法的调用体验一致，无需额外实例化查询类
• 上下文关联紧密：查询方法属于DbContext体系，契合EF Core「上下文封装数据访问」的设计习惯
• 无额外DI配置：查询方法随DbContext一同注入，无需单独注册查询类服务

缺点 #

• 基类职责膨胀：查询方法增多后，基类会变得庞大，违反单一职责原则
• 测试成本高：查询与DbContext耦合，测试时需完整初始化DbContext，无法单独隔离查询逻辑
• 扩展性受限：后续新增DbContext子类必须继承该基类才能使用查询方法，灵活性不足

优点 #

• 职责分离：查询逻辑封装在独立类中，DbContext仅负责数据连接和实体映射，符合单一职责原则
• 易测试：可传入Mock的DbContext实例单独测试查询逻辑，无需初始化完整数据库上下文
• 扩展性强：新增查询只需添加/扩展查询类，无需修改DbContext及其基类，对现有代码无侵入
• 复用性高：同一查询类可被任意DbContext实例调用，完全满足「查询支持任意上下文」的核心要求

缺点 #

• 调用步骤繁琐：每次查询需先获取查询类实例（注入或手动实例化），再传入DbContext，比基类方法多一步操作
• 额外配置成本：查询类需注册到DI容器，增加了服务配置的工作量
• 上下文感知弱：查询类与DbContext松散耦合，若查询依赖DbContext的特定配置，需额外处理适配逻辑

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