ASP.NET Core中是否应向仓储层传递表达式？哪种实现更优？

这两种方式没有绝对的最优解，核心要围绕仓储模式的核心目标——封装数据访问逻辑、隔离业务层与ORM耦合来判断：

方式一：泛型仓储传递表达式 #

• 适用场景：一次性的、业务专属的复杂查询，或者项目初期快速迭代阶段。
• 优势：灵活性拉满，业务层可以快速实现任意查询逻辑，不用修改仓储层。
• 劣势：业务层直接编写EF Core表达式，导致业务层与EF Core强耦合——如果以后替换ORM（比如从EF转Dapper），所有写在业务层的表达式都要重构；同时如果多个业务场景都需要“根据ID查账户是否存在”，重复的表达式会导致维护成本上升（比如以后要加软删除判断!x.IsDeleted，得改所有地方）。

方式二：创建专门的检查方法 #

• 适用场景：多个业务场景复用的通用检查逻辑（比如根据ID、邮箱、手机号判断存在性）。
• 优势：把数据访问逻辑完全封装在仓储层，业务层只需要传入参数，不用关心底层怎么查；后续修改查询规则（比如加软删除、多条件判断）只需要改仓储里的这一个方法，保证全应用逻辑一致。
• 劣势：如果通用检查场景多，仓储类会出现大量类似IsExistingById、IsExistingByEmail的方法，导致仓储接口膨胀。

折中优化方案：Specification（规格）模式 #

如果想兼顾灵活性和封装性，解决方式二的方法膨胀问题，可以用Specification模式：

1. 定义规格基类，封装查询表达式：

public abstract class Specification<T>
{
    public abstract Expression<Func<T, bool>> ToExpression();
}

public class AccountByIdSpecification : Specification<Account>
{
    private readonly Guid _accountId;

    public AccountByIdSpecification(Guid accountId)
    {
        _accountId = accountId;
    }

    public override Expression<Func<Account, bool>> ToExpression()
    {
        return x => x.Id == _accountId && !x.IsDeleted; // 统一维护查询规则
    }
}

2. 仓储层提供通用的AnyAsync方法接收规格：

public async Task<bool> AnyAsync(Specification<T> spec)
{
    return await _dbSet.AnyAsync(spec.ToExpression());
}

3. 业务层调用：

var spec = new AccountByIdSpecification(accountId);
var isAccountExisting = await _accountRepository.AnyAsync(spec);

if (!isAccountExisting)
{
    throw new EntityNotFoundException(nameof(Account), accountId.Value);
}

这种方式既把查询逻辑封装在规格类中（隔离业务层与ORM），又避免了仓储层方法爆炸，同时保留了灵活扩展查询的能力。

内容的提问来源于stack exchange，提问作者Lê Rôn