EF Core规范模式实战：封装查询逻辑提升代码可维护性-平芜编程栈

这次我们来看一个在 EF Core 项目中提升代码可维护性的实用模式：规范模式。如果你在项目中遇到过查询逻辑散落在各个服务层、重复的 Where 条件难以复用、或者单元测试时难以模拟查询逻辑的问题，那么这个模式值得你花十分钟了解一下。它不是一个新的框架，而是一种设计思想，核心是使用“规范”对象来封装查询条件，让查询逻辑变得清晰、可组合且易于测试。

简单来说，规范模式就是将你的查询条件（比如Where(x => x.IsActive && x.CreatedDate > DateTime.Now.AddDays(-7))）封装成一个独立的、可复用的类。这样做的好处是，你可以像搭积木一样组合不同的查询条件，避免在业务逻辑中直接编写复杂的 LINQ 表达式，从而让代码更干净，也更容易应对变化。

本文将带你从零开始，理解规范模式的核心概念，并手把手演示如何在 EF Core 项目中实现它。我们会重点关注它的实际应用：如何定义规范、如何组合规范、如何在仓储层或查询服务中使用，以及它如何简化你的单元测试。如果你关心代码结构、团队协作和长期维护成本，这篇文章可以直接收藏。

1. 核心能力速览

在深入代码之前，我们先通过一个表格快速了解规范模式能为你带来什么，以及它的典型应用场景。

能力项	说明
核心目标	封装和复用查询业务逻辑，实现关注点分离。
技术实现	基于 C# 的表达式树和 EF Core 的`IQueryable<T>`接口。
主要功能	1.条件封装：将`Where`条件封装为独立类。 2.逻辑组合：支持与（And）、或（Or）、非（Not）组合。 3.排序与分页：可扩展以包含`OrderBy`、`Skip`、`Take`逻辑。 4.查询复用：同一规范可在不同查询场景中复用。
推荐使用场景	1. 复杂动态查询（如高级搜索过滤器）。 2. 查询逻辑需要在多处复用。 3. 需要为查询逻辑编写单元测试。 4. 希望业务层与数据访问层解耦。
不适用场景	1. 极其简单的、一次性的查询。 2. 对性能有极致要求，需要手动优化 SQL 的场景（规范模式生成的 SQL 与手写 LINQ 一致）。
启动/集成方式	非独立服务，需作为类库集成到现有 EF Core 项目中。
硬件/环境门槛	无特殊要求，与运行 EF Core 应用的环境一致。

2. 适用场景与使用边界

规范模式并非银弹，理解其适用边界能帮助你更好地决策。

它非常适合以下场景：

复杂搜索/过滤：例如电商后台的商品搜索，需要根据价格区间、分类、品牌、库存状态、关键词等多个动态条件组合查询。将这些条件封装成不同的规范，组合起来非常清晰。
权限数据过滤：在多租户系统或数据权限复杂的系统中，查询数据时往往需要附加“当前用户所属部门”、“数据可见范围”等条件。将这些权限条件封装为规范，可以确保所有查询自动应用，避免遗漏。
领域驱动设计：在 DDD 中，规范模式是领域层表达查询意图的一种方式，可以将领域知识（如“获取所有未过期的活跃订单”）封装起来，供应用层调用。
单元测试：你可以轻松地 Mock 一个规范对象，来测试服务层逻辑，而无需真正连接数据库或构建复杂的IQueryable测试数据。

它的使用边界和注意事项：

性能：规范模式最终生成的是标准的 LINQ 表达式树，由 EF Core 转换为 SQL，其性能与直接手写 LINQ 查询相当。但过度复杂的规范组合可能生成低效的 SQL，仍需通过 EF Core 的日志（如“慢查询日志”）进行监控和优化。
简单查询：对于DbContext.Users.FindAsync(id)或简单的Where(x => x.Id == id)，直接编写 LINQ 更简洁，引入规范模式反而增加了复杂度。
过度设计风险：在小型项目或查询逻辑极其稳定的模块中，引入规范模式可能带来不必要的抽象层。评估其带来的维护收益是否大于实现成本。
理解成本：团队需要理解表达式树和IQueryable的延迟执行特性，否则可能在无意中导致客户端评估（Client-side evaluation）或 N+1 查询问题。

3. 环境准备与前置条件

在开始编码前，请确保你的开发环境满足以下要求。规范模式本身不依赖特定外部库，但需要 EF Core 作为基础。

开发环境：
- 操作系统：Windows 10/11, macOS, 或 Linux 发行版。
- IDE/编辑器：Visual Studio 2022+、Visual Studio Code 或 Rider。
- .NET SDK：需要 .NET 6.0、.NET 8.0 或更高版本。本文示例基于 .NET 8。
项目与依赖：
- 一个已有的或新建的 ASP.NET Core Web API 或类库项目。
- 通过 NuGet 安装Microsoft.EntityFrameworkCore和对应的数据库提供程序（如Microsoft.EntityFrameworkCore.SqlServer）。
- 一个已定义的 DbContext 和实体类。例如，我们用一个简单的Product（产品）实体来演示。
```
// 示例实体 public class Product { public int Id { get; set; } public string Name { get; set; } public decimal Price { get; set; } public int StockQuantity { get; set; } public bool IsActive { get; set; } public DateTime CreatedDate { get; set; } public int CategoryId { get; set; } public Category Category { get; set; } }
```
知识准备：
- 熟悉 C# 语言特性，特别是 Lambda 表达式和泛型。
- 理解 EF Core 的基本用法和IQueryable<T>的延迟查询机制。
- 对表达式树有基本概念（知道Expression<Func<T, bool>>是什么即可）。

4. 核心概念与基础实现

让我们从最核心的接口开始，一步步构建规范模式的基础设施。

4.1 定义规范接口

规范模式的核心是一个接口，它定义了“某个对象是否满足特定条件”。在查询上下文中，这个条件就是针对实体T的布尔表达式。

// Specification.cs using System.Linq.Expressions; namespace YourProject.Specifications { public interface ISpecification<T> { // 核心：获取封装了查询条件的表达式树 Expression<Func<T, bool>> Criteria { get; } // 可扩展点：包含的导航属性（用于 Include） List<Expression<Func<T, object>>> Includes { get; } // 可扩展点：排序表达式 Expression<Func<T, object>> OrderBy { get; } Expression<Func<T, object>> OrderByDescending { get; } // 可扩展点：分页 int Take { get; } int Skip { get; } bool IsPagingEnabled { get; } } }

这个ISpecification<T>接口是规范模式的基石。Criteria属性是最重要的，它直接对应Where子句。其他属性如Includes、OrderBy等是为了让规范能描述更完整的查询。

4.2 实现基础规范抽象类

接下来，我们实现一个基础的抽象类，它提供了Includes、OrderBy等属性的存储和设置方法，并实现了Criteria的核心逻辑。

// BaseSpecification.cs using System.Linq.Expressions; namespace YourProject.Specifications { public abstract class BaseSpecification<T> : ISpecification<T> { // 核心查询条件 public Expression<Func<T, bool>> Criteria { get; private set; } // 包含的导航属性列表 public List<Expression<Func<T, object>>> Includes { get; } = new List<Expression<Func<T, object>>>(); // 排序 public Expression<Func<T, object>> OrderBy { get; private set; } public Expression<Func<T, object>> OrderByDescending { get; private set; } // 分页 public int Take { get; private set; } public int Skip { get; private set; } public bool IsPagingEnabled { get; private set; } // 构造函数：用于创建带有查询条件的规范 protected BaseSpecification(Expression<Func<T, bool>> criteria) { Criteria = criteria; } // 构造函数：用于创建无初始条件的规范（后续可通过方法添加） protected BaseSpecification() { } // 保护方法：供派生类设置条件（用于无参构造时后续构建） protected void SetCriteria(Expression<Func<T, bool>> criteria) { Criteria = criteria; } // 添加 Include 导航属性 protected void AddInclude(Expression<Func<T, object>> includeExpression) { Includes.Add(includeExpression); } // 设置升序排序 protected void ApplyOrderBy(Expression<Func<T, object>> orderByExpression) { OrderBy = orderByExpression; } // 设置降序排序 protected void ApplyOrderByDescending(Expression<Func<T, object>> orderByDescendingExpression) { OrderByDescending = orderByDescendingExpression; } // 启用分页 protected void ApplyPaging(int skip, int take) { Skip = skip; Take = take; IsPagingEnabled = true; } } }

4.3 创建第一个具体规范

现在，我们可以基于BaseSpecification创建具体的业务规范了。例如，一个“获取所有活跃产品”的规范。

// ActiveProductSpecification.cs namespace YourProject.Specifications { public class ActiveProductSpecification : BaseSpecification<Product> { public ActiveProductSpecification() : base(p => p.IsActive == true) // 在基类构造函数中设置条件 { // 可以同时添加 Include，例如包含分类信息 AddInclude(p => p.Category); // 可以设置默认排序 ApplyOrderBy(p => p.CreatedDate); } } }

看，这个ActiveProductSpecification类非常简洁。它清晰地表达了业务意图：“一个活跃产品的规范”。所有的查询细节都被封装在里面。

5. 构建规范评估器（Specification Evaluator）

有了规范对象，我们还需要一个工具，能将规范应用到 EF Core 的DbSet<T>或IQueryable<T>上，生成最终的查询。这就是规范评估器。

// SpecificationEvaluator.cs using Microsoft.EntityFrameworkCore; namespace YourProject.Specifications { public class SpecificationEvaluator<T> where T : class { public static IQueryable<T> GetQuery(IQueryable<T> inputQuery, ISpecification<T> specification) { var query = inputQuery; // 1. 应用 Where 条件 if (specification.Criteria != null) { query = query.Where(specification.Criteria); } // 2. 应用 Includes (贪婪加载) query = specification.Includes .Aggregate(query, (current, include) => current.Include(include)); // 3. 应用排序 if (specification.OrderBy != null) { query = query.OrderBy(specification.OrderBy); } else if (specification.OrderByDescending != null) { query = query.OrderByDescending(specification.OrderByDescending); } // 4. 应用分页 if (specification.IsPagingEnabled) { query = query.Skip(specification.Skip).Take(specification.Take); } return query; } } }

这个SpecificationEvaluator是一个静态工具类。它接收一个初始的IQueryable<T>和一个规范对象，然后按顺序应用条件、包含、排序和分页，返回一个新的IQueryable<T>。关键点：它返回的仍然是IQueryable，这意味着查询还没有执行，EF Core 会在最终迭代（如.ToListAsync()）时，将所有操作合并成一条高效的 SQL 语句。

6. 在仓储层或服务层中使用规范

如何将规范用起来？通常我们在仓储模式中集成，或者直接在服务层调用。这里展示一个集成到泛型仓储中的方法。

6.1 扩展 IRepository 接口和实现

首先，在现有的仓储接口中添加基于规范的方法。

// IRepository.cs (部分代码) using System.Linq.Expressions; namespace YourProject.Interfaces { public interface IRepository<T> where T : class { // ... 其他方法 (Add, Update, Delete, GetById等) // 基于规范获取单个实体 Task<T?> GetSingleBySpecAsync(ISpecification<T> spec, CancellationToken cancellationToken = default); // 基于规范获取列表 Task<List<T>> GetListBySpecAsync(ISpecification<T> spec, CancellationToken cancellationToken = default); // 基于规范计数 Task<int> CountBySpecAsync(ISpecification<T> spec, CancellationToken cancellationToken = default); } }

然后，在仓储实现类中调用我们之前写的SpecificationEvaluator。

// EfRepository.cs (部分代码) using Microsoft.EntityFrameworkCore; using YourProject.Specifications; using YourProject.Interfaces; namespace YourProject.Data { public class EfRepository<T> : IRepository<T> where T : class { protected readonly DbContext _dbContext; protected readonly DbSet<T> _dbSet; public EfRepository(DbContext dbContext) { _dbContext = dbContext; _dbSet = _dbContext.Set<T>(); } public virtual async Task<T?> GetSingleBySpecAsync(ISpecification<T> spec, CancellationToken cancellationToken = default) { return await ApplySpecification(spec).FirstOrDefaultAsync(cancellationToken); } public virtual async Task<List<T>> GetListBySpecAsync(ISpecification<T> spec, CancellationToken cancellationToken = default) { return await ApplySpecification(spec).ToListAsync(cancellationToken); } public virtual async Task<int> CountBySpecAsync(ISpecification<T> spec, CancellationToken cancellationToken = default) { return await ApplySpecification(spec, false).CountAsync(cancellationToken); // false 表示不应用分页和排序 } // 核心方法：将规范应用到 DbSet private IQueryable<T> ApplySpecification(ISpecification<T> spec, bool applyPagingAndSorting = true) { // 从 DbSet 开始 var query = _dbSet.AsQueryable(); // 使用评估器 query = SpecificationEvaluator<T>.GetQuery(query, spec); // 注意：对于 Count 操作，我们通常不需要排序和分页 if (!applyPagingAndSorting) { // 可以创建一个不包含排序和分页逻辑的临时评估逻辑，这里简单返回应用了Where和Include的查询 // 更严谨的做法是修改评估器或规范接口 return query; } return query; } } }

6.2 在业务服务中调用

现在，在业务服务层，使用规范变得非常直观和语义化。

// ProductService.cs using YourProject.Specifications; namespace YourProject.Services { public class ProductService { private readonly IRepository<Product> _productRepository; public ProductService(IRepository<Product> productRepository) { _productRepository = productRepository; } public async Task<List<Product>> GetActiveProductsAsync() { // 创建规范实例 var spec = new ActiveProductSpecification(); // 使用仓储方法查询 var activeProducts = await _productRepository.GetListBySpecAsync(spec); return activeProducts; } } }

对比一下，如果没有规范模式，你可能需要在服务层写_dbContext.Products.Where(p => p.IsActive).Include(p => p.Category).OrderBy(p => p.CreatedDate).ToListAsync()。当这个逻辑在多个地方出现时，规范模式的优势就体现出来了。

7. 高级功能：规范组合与构建器

规范模式的强大之处在于组合。我们可以创建更复杂的规范，而无需修改现有代码。

7.1 组合规范（And, Or, Not）

我们需要创建一些扩展方法或新的规范类来支持逻辑组合。这里展示一种使用表达式树组合器的实现方式。

首先，需要一个表达式组合器工具类：

// ExpressionCombiner.cs using System.Linq.Expressions; namespace YourProject.Specifications { public static class ExpressionCombiner { public static Expression<Func<T, bool>> And<T>( Expression<Func<T, bool>> left, Expression<Func<T, bool>> right) { if (left == null) return right; if (right == null) return left; var parameter = Expression.Parameter(typeof(T)); var leftVisitor = new ReplaceExpressionVisitor(left.Parameters[0], parameter); var leftExpr = leftVisitor.Visit(left.Body); var rightVisitor = new ReplaceExpressionVisitor(right.Parameters[0], parameter); var rightExpr = rightVisitor.Visit(right.Body); return Expression.Lambda<Func<T, bool>>( Expression.AndAlso(leftExpr, rightExpr), parameter); } public static Expression<Func<T, bool>> Or<T>( Expression<Func<T, bool>> left, Expression<Func<T, bool>> right) { // 实现类似 And，使用 Expression.OrElse // 为简洁省略，实际项目需补充 throw new NotImplementedException(); } private class ReplaceExpressionVisitor : ExpressionVisitor { private readonly Expression _oldValue; private readonly Expression _newValue; public ReplaceExpressionVisitor(Expression oldValue, Expression newValue) { _oldValue = oldValue; _newValue = newValue; } public override Expression Visit(Expression node) { return node == _oldValue ? _newValue : base.Visit(node); } } } }

然后，可以创建支持组合的规范基类或扩展方法：

// CompositeSpecification.cs namespace YourProject.Specifications { public abstract class CompositeSpecification<T> : BaseSpecification<T> { protected CompositeSpecification(Expression<Func<T, bool>> criteria) : base(criteria) { } public CompositeSpecification<T> And(ISpecification<T> other) { var combinedCriteria = ExpressionCombiner.And(this.Criteria, other.Criteria); // 注意：这里简化处理，实际组合时还需考虑 Includes 等的合并 // 可以返回一个新的规范实例，或者修改当前实例的 Criteria // 这里演示返回新实例的思路 return new DynamicSpecification<T>(combinedCriteria); } } // 一个用于动态组合的规范类 public class DynamicSpecification<T> : CompositeSpecification<T> { public DynamicSpecification(Expression<Func<T, bool>> criteria) : base(criteria) { } } }

7.2 使用规范构建器（Specification Builder）

对于动态查询（如前端传入的多个过滤条件），使用构建器模式可以更优雅地创建规范。

// ProductSpecificationBuilder.cs namespace YourProject.Specifications { public class ProductSpecificationBuilder { private Expression<Func<Product, bool>> _criteria = p => true; // 初始为 true private readonly List<Expression<Func<Product, object>>> _includes = new(); private Expression<Func<Product, object>> _orderBy; private bool _orderByDesc; private int? _skip; private int? _take; public ProductSpecificationBuilder WithNameContaining(string keyword) { if (!string.IsNullOrWhiteSpace(keyword)) { _criteria = ExpressionCombiner.And(_criteria, p => p.Name.Contains(keyword)); } return this; } public ProductSpecificationBuilder WithPriceInRange(decimal? minPrice, decimal? maxPrice) { if (minPrice.HasValue) { _criteria = ExpressionCombiner.And(_criteria, p => p.Price >= minPrice.Value); } if (maxPrice.HasValue) { _criteria = ExpressionCombiner.And(_criteria, p => p.Price <= maxPrice.Value); } return this; } public ProductSpecificationBuilder WithCategoryId(int? categoryId) { if (categoryId.HasValue) { _criteria = ExpressionCombiner.And(_criteria, p => p.CategoryId == categoryId.Value); } return this; } public ProductSpecificationBuilder IncludeCategory() { _includes.Add(p => p.Category); return this; } public ProductSpecificationBuilder OrderByPrice(bool descending = false) { _orderBy = p => p.Price; _orderByDesc = descending; return this; } public ProductSpecificationBuilder Paginate(int page, int pageSize) { _skip = (page - 1) * pageSize; _take = pageSize; return this; } public ISpecification<Product> Build() { var spec = new DynamicSpecification<Product>(_criteria); // 这里需要将_includes, _orderBy等设置到spec中，需要扩展DynamicSpecification或使用新类 // 为演示简洁，假设有一个方法可以设置这些属性 // spec.SetIncludes(_includes); // if (_orderBy != null) spec.ApplyOrderBy(_orderBy); // if (_skip.HasValue && _take.HasValue) spec.ApplyPaging(_skip.Value, _take.Value); return spec; } } }

在服务层中使用构建器：

public async Task<List<Product>> SearchProductsAsync(string keyword, decimal? minPrice, decimal? maxPrice, int? categoryId, int page, int pageSize) { var specBuilder = new ProductSpecificationBuilder() .WithNameContaining(keyword) .WithPriceInRange(minPrice, maxPrice) .WithCategoryId(categoryId) .IncludeCategory() .OrderByPrice(descending: true) .Paginate(page, pageSize); var spec = specBuilder.Build(); return await _productRepository.GetListBySpecAsync(spec); }

这种链式调用的方式，让动态查询的构建过程非常清晰。

8. 功能测试与效果验证

如何验证我们的规范模式实现是正确且高效的呢？我们可以从单元测试和集成测试两个层面进行。

8.1 单元测试：测试规范本身

规范是纯内存对象，不依赖数据库，非常适合单元测试。

// ActiveProductSpecificationTests.cs using Xunit; using YourProject.Specifications; namespace YourProject.Tests.Unit.Specifications { public class ActiveProductSpecificationTests { [Fact] public void Criteria_Should_Filter_Active_Products() { // Arrange var spec = new ActiveProductSpecification(); var products = new List<Product> { new Product { Id = 1, Name = "Active Product", IsActive = true }, new Product { Id = 2, Name = "Inactive Product", IsActive = false }, new Product { Id = 3, Name = "Another Active", IsActive = true } }.AsQueryable(); // Act var filtered = products.Where(spec.Criteria.Compile()); // 编译表达式在内存中测试 // Assert Assert.Equal(2, filtered.Count()); Assert.All(filtered, p => Assert.True(p.IsActive)); } [Fact] public void Includes_Should_Contain_Category() { // Arrange var spec = new ActiveProductSpecification(); // Act & Assert Assert.Single(spec.Includes); // 可以通过检查表达式树来验证，这里简单断言数量 } } }

8.2 集成测试：测试仓储与规范的结合

使用内存数据库（如 EF Core 的 In-Memory Database 或 SQLite）来测试规范与数据库的交互。

// ProductRepositorySpecificationTests.cs using Microsoft.EntityFrameworkCore; using YourProject.Data; using YourProject.Specifications; using Xunit; namespace YourProject.Tests.Integration.Data { public class ProductRepositorySpecificationTests { private readonly DbContextOptions<YourDbContext> _dbContextOptions; public ProductRepositorySpecificationTests() { _dbContextOptions = new DbContextOptionsBuilder<YourDbContext>() .UseInMemoryDatabase(databaseName: $"TestDb_{Guid.NewGuid()}") // 唯一名避免冲突 .Options; } [Fact] public async Task GetListBySpecAsync_WithActiveSpec_Should_Return_Only_Active_Products() { // Arrange await using var context = new YourDbContext(_dbContextOptions); var repository = new EfRepository<Product>(context); // 添加测试数据 context.Products.AddRange( new Product { Id = 1, Name = "P1", IsActive = true }, new Product { Id = 2, Name = "P2", IsActive = false }, new Product { Id = 3, Name = "P3", IsActive = true } ); await context.SaveChangesAsync(); var spec = new ActiveProductSpecification(); // Act var result = await repository.GetListBySpecAsync(spec); // Assert Assert.Equal(2, result.Count); Assert.All(result, p => Assert.True(p.IsActive)); Assert.Contains(result, p => p.Id == 1); Assert.Contains(result, p => p.Id == 3); Assert.DoesNotContain(result, p => p.Id == 2); } } }

8.3 验证生成的 SQL

为了确保规范模式没有引入性能问题，最关键的一步是检查它生成的 SQL 是否合理。在开发或测试环境中，启用 EF Core 的日志记录。

// 在 Startup.cs 或 Program.cs 中配置 builder.Services.AddDbContext<YourDbContext>(options => options.UseSqlServer(connectionString) .LogTo(Console.WriteLine, LogLevel.Information) // 输出到控制台 .EnableSensitiveDataLogging()); // 可选，显示参数值

运行一个使用复杂组合规范的查询，观察控制台输出的 SQL。它应该是一条整合了所有WHERE、JOIN(来自Include)、ORDER BY和OFFSET FETCH的语句，与手写 LINQ 生成的 SQL 一致。如果出现了N+1查询或客户端评估警告，就需要检查规范中Include的使用或表达式是否正确。

9. 常见问题与排查方法

在实现和使用规范模式时，你可能会遇到一些典型问题。下表列出了常见现象、原因和解决方案。

问题现象	可能原因	排查方式	解决方案
编译错误：无法将表达式树转换为 SQL	在规范`Criteria`中使用了 C# 方法或逻辑，这些方法无法被 EF Core 的查询提供程序翻译。	检查`Criteria`表达式中的方法调用（如`.ToString()`,`.Substring()`）或复杂的逻辑运算。查看 EF Core 异常信息。	1. 确保表达式中的操作是 EF Core 支持的。 2. 将无法翻译的逻辑移到查询之外，先获取数据到内存再处理。 3. 使用`IEnumerable`后在内存中过滤（仅适用于小数据集）。
查询性能慢，日志显示多条 SQL	规范中可能遗漏了必要的`Include`，导致延迟加载产生 N+1 查询。或者规范组合导致索引失效。	1. 检查 EF Core 日志，看是否在执行循环查询。 2. 使用 SQL Server Profiler 或数据库监控工具分析生成的 SQL 执行计划。	1. 在规范中添加必要的`AddInclude`。 2. 检查组合查询的`WHERE`条件是否使用了索引列。 3. 考虑使用`AsNoTracking()`如果不需要变更跟踪。
分页结果不正确	1. 排序规则不明确，导致分页数据不稳定。 2.`Skip`和`Take`在规范中设置错误。	1. 检查规范是否设置了`OrderBy`。 2. 在分页前，确保有确定的排序顺序。 3. 调试查看`spec.Skip`和`spec.Take`的值。	1.始终为分页查询指定排序（`OrderBy`或`OrderByDescending`）。 2. 验证分页参数计算逻辑（如`(page-1)*pageSize`）。
规范组合（And/Or）后查询结果为空或错误	表达式组合器逻辑有误，组合后的表达式树结构不正确。	编写单元测试，用简单的内存数据测试组合规范。使用调试器查看组合后的`Criteria`表达式树。	仔细检查`ExpressionCombiner`中的访问者模式实现，确保参数替换正确。考虑使用成熟的第三方库，如`LinqKit`的`PredicateBuilder`。
单元测试时 Mock 规范困难	`ISpecification<T>`接口包含表达式树属性，Mock 起来较复杂。	-	1. 改为测试具体规范类（如`ActiveProductSpecification`），它们是纯逻辑，易测试。 2. 如果必须 Mock，可以使用`Moq`库的`.SetupGet`来设置属性返回值。
“SpecificationEvaluator”中应用 Include 后，排序/分页属性被忽略	在`GetQuery`方法中，`Aggregate`处理`Include`后返回的`IQueryable`可能丢失了原始查询的某些上下文（虽然不常见）。或者自定义的`ApplySpecification`方法逻辑有误。	检查`SpecificationEvaluator.GetQuery`方法的执行顺序和返回结果。	确保`SpecificationEvaluator`中各个步骤（Where, Include, OrderBy, Skip/Take）是顺序执行且作用于同一个`query`变量。参考 Ardalis.Specification 等开源库的实现。

10. 最佳实践与使用建议

为了让规范模式在你的项目中发挥最大价值，遵循以下最佳实践：

命名清晰：规范类名应明确表达其业务意图，如ProductInStockSpecification、UserWithRoleSpecification、OrdersFromLastWeekSpecification。
保持单一职责：一个规范最好只封装一个独立的业务条件。复杂的查询通过组合多个简单规范来实现，而不是创建一个庞大的“万能”规范。
谨慎使用 Include：只在确实需要立即加载关联数据时才在规范中添加Include。过度使用Include会导致查询复杂和性能下降。考虑使用投影（Select）来只获取需要的字段。
为分页强制排序：这是一个黄金法则。没有确定排序顺序的分页查询，其结果顺序是不确定的，可能导致数据重复或丢失。总是在分页规范中设置OrderBy。
考虑缓存规范实例：如果某个规范是无状态的（即其Criteria不依赖运行时参数），可以将其创建为静态只读实例，避免重复创建。
```
public static class ProductSpecifications { public static readonly ISpecification<Product> ActiveProducts = new ActiveProductSpecification(); }
```
与 CQRS 结合：在 CQRS 架构中，规范模式非常适合用在查询端（Query Side），用来构建复杂的查询对象。
不要滥用：如前所述，对于简单查询，直接使用 LINQ 更合适。规范模式是应对复杂性和提升可维护性的工具，而不是所有查询的标配。
团队共识：在团队中推广使用前，确保所有成员理解其原理和优势，并建立一致的实现规范。

规范模式是清理 EF Core 查询代码库的一把利器。它通过将查询条件提升为一等公民，显著提升了代码的可读性、可复用性和可测试性。虽然初期需要投入时间搭建基础设施，但对于中大型项目或查询逻辑复杂的场景，这笔投资会在长期的维护和扩展中带来丰厚的回报。建议你从项目中最混乱的一处查询逻辑开始，尝试用规范模式重构它，亲身体验其带来的整洁与便利。