如何优化EF Core软删除查询的仓储方法，避免重复实现？

针对你遇到的仓储方法重复、命名冗长的问题，以下是几种实用的优化方案，可根据项目架构选择：

方案一：通用仓储基类封装过滤逻辑 #

将软删除的过滤逻辑抽离到通用基类中，所有仓储继承该基类，避免每个仓储重复实现判断逻辑。

步骤： #

1. 定义软删除实体的统一接口：

public interface ISoftDeletable
{
    DeletionStatus DeletionStatus { get; set; }
}

让YourObject等需软删除的实体实现该接口，统一规范实体结构。

2. 实现通用仓储基类：

public abstract class BaseRepository<T> where T : class, ISoftDeletable
{
    protected readonly DbContext _context;
    protected DbSet<T> DbSet => _context.Set<T>();

    public BaseRepository(DbContext context)
    {
        _context = context;
    }

    // 核心：统一构建查询，处理软删除过滤
    protected IQueryable<T> BuildQuery(bool includeDeleted = false)
    {
        var query = DbSet.AsQueryable();
        return includeDeleted ? query.IgnoreQueryFilters() : query;
    }

    // 通用示例方法：根据ID查询
    public async Task<T?> GetByIdAsync(Guid id, bool includeDeleted = false)
    {
        return await BuildQuery(includeDeleted)
            .FirstOrDefaultAsync(x => x.Id == id);
    }
}

3. 具体仓储继承基类并扩展：

public class YourObjectRepository : BaseRepository<YourObject>
{
    public YourObjectRepository(DbContext context) : base(context) { }

    // 自定义带关联查询的方法
    public async Task<YourObject?> GetByIdWithFilesAsync(Guid id, bool includeDeleted = false)
    {
        return await BuildQuery(includeDeleted)
            .Include(x => x.Files)
            .FirstOrDefaultAsync(x => x.Id == id);
    }
}

优势：统一管理软删除逻辑，新增仓储时无需重复编写过滤代码，方法名简洁易维护。

方案二：扩展方法封装忽略过滤器逻辑 #

通过给IQueryable<T>添加扩展方法，简化仓储中忽略过滤器的调用，避免重复的if判断。

实现扩展方法： #

public static class SoftDeleteQueryExtensions
{
    public static IQueryable<T> IncludeSoftDeleted<T>(this IQueryable<T> query) 
        where T : ISoftDeletable
    {
        return query.IgnoreQueryFilters();
    }
}

在仓储中使用： #

public async Task<YourObject?> GetByIdWithFilesAsync(Guid id, bool includeDeleted = false)
{
    var query = _context.YourObjects.AsQueryable();
    if (includeDeleted)
    {
        query = query.IncludeSoftDeleted();
    }
    return await query.Include(x => x.Files).FirstOrDefaultAsync(x => x.Id == id);
}

优势：无需修改仓储基类，灵活度高，适合已有大量仓储类的项目快速改造。

方案三：默认参数简化方法签名 #

直接在原有方法中添加bool includeDeleted = false的默认参数，合并两个重复方法，避免冗长命名。

改造后的仓储方法： #

// 合并原有的GetByIdWithFilesAsync和GetByIdWithFilesWithIgnoreFiltersAsync
public async Task<YourObject?> GetByIdWithFilesAsync(Guid id, bool includeDeleted = false)
{
    var query = _context.YourObjects.AsQueryable();
    if (includeDeleted)
    {
        query = query.IgnoreQueryFilters();
    }
    return await query.Include(x => x.Files).FirstOrDefaultAsync(x => x.Id == id);
}

调用方式： #

// 默认查询未删除数据
var normalObj = await _yourObjectRepo.GetByIdWithFilesAsync(objId);
// 显式指定查询包含已删除数据
var allObj = await _yourObjectRepo.GetByIdWithFilesAsync(objId, includeDeleted: true);

优势：改动最小，快速解决方法重复问题，方法名保持简洁。

方案对比与推荐 #

• 若所有仓储都需要软删除逻辑：优先选择方案一（通用基类），实现逻辑统一，后续维护更省心。
• 若项目已有大量仓储类，不想重构基类：选择方案二（扩展方法）或方案三（默认参数），快速完成改造。
• 不推荐自定义属性方案：依赖反射实现，性能开销大，代码可读性不如上述方案。

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