企业官网建设流程全解析

你是否遇到过这样的场景：一个简单的列表查询，随着业务发展，查询条件越来越多，Where子句越写越长，最终变成一个几百行的“意大利面条式”查询方法？或者，同样的查询逻辑（如“查询已发布且未删除的文章”）在控制器、服务层、仓储层被重复编写，一旦业务规则变更，就需要满世界修改？

这不是代码冗余的问题，而是查询逻辑缺乏组织和复用的典型症状。在 Entity Framework Core 项目中，这个问题尤为突出。开发者往往将查询逻辑直接写在DbContext或仓储方法中，导致代码难以测试、维护和扩展。

今天要讨论的“规范模式”，正是解决这一痛点的利器。它不是一个新概念，但在 EF Core 的语境下，它能将你的查询从混乱的IQueryable拼接中解放出来，实现逻辑的封装、复用和清晰分离。更重要的是，它能与“查询清理”的思想结合，帮助你构建出高性能、可维护的数据访问层。

本文将带你深入理解如何用规范模式来“清理”你的 EF Core 查询。你会看到，这不仅仅是写一个ISpecification接口那么简单，而是关乎如何设计一个清晰、健壮且易于测试的查询架构。

1. 这篇文章真正要解决的问题

很多开发者对 EF Core 又爱又恨。“爱”的是它的开发效率，用 LINQ 就能操作数据库；“恨”的是随着项目复杂度的提升，查询代码会迅速变得难以控制。我们面临的核心问题有几个：

1. 逻辑分散与重复：判断“有效用户”的逻辑可能在用户查询、订单查询、报表查询中重复出现。一旦“有效”的定义改变（比如增加“邮箱已验证”条件），就需要修改多处。
2. 可测试性差：一个包含复杂Where、Include、OrderBy的查询方法很难进行单元测试。你通常需要启动一个内存数据库或连接真实数据库，这属于集成测试，速度慢且不稳定。
3. 组合能力弱：当需要动态组合查询条件时（如前端传入多个过滤参数），代码中会充斥大量的if语句来拼接IQueryable，可读性急剧下降。
4. 关注点混淆：数据访问逻辑（怎么查）和业务逻辑（为什么查）经常混杂在一起，违反了单一职责原则。

规范模式的核心价值，就在于它将查询条件、排序规则、分页逻辑以及数据投影（Select）等封装成一个独立的、可复用的“规范”对象。这个对象本身不执行查询，它只是描述了一个查询应该是什么样子。然后，由一个统一的“规约执行器”来应用这些规范，生成最终的IQueryable或执行查询。

通过这种方式，我们实现了“查询逻辑”的客体化。你可以像组合乐高积木一样组合不同的规范，也可以轻松地对单个规范进行单元测试。这就是对 EF Core 查询代码最彻底的“清理”。

2. 基础概念与核心原理

在深入代码之前，我们先厘清几个关键概念。

什么是规范模式？规范模式是一种特定领域的设计模式，它使用一个对象来封装业务规则，用于判断另一个对象是否满足该规则。在数据访问层，这个“规则”就是查询条件。我们将“查询已发布文章”这个规则，封装成一个PublishedPostSpecification类的实例。

核心组件一个典型的规范模式实现包含以下部分：

1. 规约接口：定义规约的基本契约，通常包含一个IsSatisfiedBy方法（用于内存对象判断）或一个Apply方法（用于构建IQueryable）。在 EF Core 中，我们更关注后者。
2. 具体规约类：实现接口，封装具体的查询逻辑。例如ActiveUserSpecification、ProductInStockSpecification。
3. 组合器：提供And、Or、Not等方法，允许将多个规约组合成一个新的规约。这是实现逻辑复用的关键。
4. 规约求值器/执行器：负责将规约对象应用到IQueryable上，并最终执行查询，返回数据。

与仓储模式的关系规范模式常与仓储模式结合使用。传统的仓储接口可能会有GetActiveUsers、GetExpiredOrders等方法，导致方法爆炸。引入规范模式后，仓储接口可以简化为：

public interface IRepository<T> where T : class { Task<T?> GetByIdAsync(int id); Task<IEnumerable<T>> GetAllAsync(); // 核心变化：接受规约进行查询 Task<IEnumerable<T>> FindAsync(ISpecification<T> spec); // 可能还有 FindPagedAsync, CountAsync 等 }

这样，仓储只负责基础 CRUD 和规约的执行，而具体的查询逻辑则由规约类定义，职责更加清晰。

“清理”体现在何处？

• 逻辑归类：相似的查询条件被归类到同一个规约中。
• 消除重复：通用逻辑通过规约复用。
• 动态组合：通过组合器灵活应对复杂查询场景。
• 易于测试：可以单独测试一个规约是否正确地构建了表达式树。

3. 环境准备与前置条件

为了实践本文的示例，你需要准备以下环境：

1. 开发环境：.NET 6, .NET 7, .NET 8 或更高版本。本文示例基于 .NET 8，但核心概念适用于所有支持 EF Core 的版本。
2. IDE：Visual Studio 2022、Rider 或 VS Code。
3. 数据库：示例使用 SQL Server LocalDB 或 SQLite（便于演示），但 EF Core 支持的数据库均可。
4. 项目类型：一个 ASP.NET Core Web API 或 Console 应用程序。
5. NuGet 包：
   • Microsoft.EntityFrameworkCore.SqlServer(或Microsoft.EntityFrameworkCore.Sqlite)
   • Microsoft.EntityFrameworkCore.Tools(可选，用于迁移)

你可以通过以下命令创建一个新的控制台项目并添加 EF Core 支持：

dotnet new console -n EfCoreSpecificationDemo cd EfCoreSpecificationDemo dotnet add package Microsoft.EntityFrameworkCore.SqlServer dotnet add package Microsoft.EntityFrameworkCore.Design

4. 核心流程拆解：实现一个基础的规范模式

让我们从零开始，构建一个适用于 EF Core 的规范模式实现。这个过程分为定义接口、实现基础规约、实现组合逻辑以及创建执行器。

4.1 定义规约接口

首先，我们定义一个最核心的接口ISpecification<T>。它的主要职责是提供一个方法，将自身描述的规则应用到给定的IQueryable<T>上。

// 文件路径：SpecificationPattern/ISpecification.cs namespace EfCoreSpecificationDemo.SpecificationPattern; public interface ISpecification<T> { /// <summary> /// 将规约条件应用到查询上 /// </summary> /// <param name="query">原始查询</param> /// <returns>应用了规约条件后的查询</returns> IQueryable<T> Apply(IQueryable<T> query); }

这个接口非常简单，但它是所有规约的基石。

4.2 实现抽象基类与组合器

接下来，我们实现一个抽象基类Specification<T>，它实现了ISpecification<T>接口，并提供了And,Or,Not等组合方法。这些组合方法利用了 LINQ 的Expression树。

// 文件路径：SpecificationPattern/Specification.cs using System.Linq.Expressions; namespace EfCoreSpecificationDemo.SpecificationPattern; public abstract class Specification<T> : ISpecification<T> { // 核心：一个返回布尔值的表达式树，代表查询条件 public abstract Expression<Func<T, bool>> Criteria { get; } // 可选的“包含”表达式，用于实现 Eager Loading (Include) public virtual List<Expression<Func<T, object>>> Includes { get; } = new(); // 可选的排序表达式 public virtual Expression<Func<T, object>>? OrderBy { get; private set; } public virtual Expression<Func<T, object>>? OrderByDescending { get; private set; } // 可选的翻页属性 public virtual int Take { get; private set; } public virtual int Skip { get; private set; } public virtual bool IsPagingEnabled { get; private set; } = false; /// <summary> /// 应用规约到 IQueryable /// </summary> public IQueryable<T> Apply(IQueryable<T> query) { // 1. 应用过滤条件 query = query.Where(Criteria); // 2. 应用包含（Include） query = Includes.Aggregate(query, (current, include) => current.Include(include)); // 3. 应用排序 if (OrderBy != null) query = query.OrderBy(OrderBy); else if (OrderByDescending != null) query = query.OrderByDescending(OrderByDescending); // 4. 应用分页 if (IsPagingEnabled) { query = query.Skip(Skip).Take(Take); } return query; } // 组合方法：与另一个规约进行 AND 运算 public Specification<T> And(Specification<T> other) { return new AndSpecification<T>(this, other); } // 组合方法：与另一个规约进行 OR 运算 public Specification<T> Or(Specification<T> other) { return new OrSpecification<T>(this, other); } // 组合方法：对当前规约进行 NOT 运算 public Specification<T> Not() { return new NotSpecification<T>(this); } // 构建器方法：添加 Include protected void AddInclude(Expression<Func<T, object>> includeExpression) { Includes.Add(includeExpression); } // 构建器方法：设置排序 protected void ApplyOrderBy(Expression<Func<T, object>> orderByExpression) { OrderBy = orderByExpression; OrderByDescending = null; } protected void ApplyOrderByDescending(Expression<Func<T, object>> orderByDescendingExpression) { OrderByDescending = orderByDescendingExpression; OrderBy = null; } // 构建器方法：设置分页 protected void ApplyPaging(int skip, int take) { Skip = skip; Take = take; IsPagingEnabled = true; } }

这个基类已经相当强大。它封装了过滤、包含、排序、分页等常见查询操作。注意Apply方法，它按照一个合理的顺序（过滤 -> 包含 -> 排序 -> 分页）来构建查询。

4.3 实现组合规约类

我们需要实现AndSpecification、OrSpecification和NotSpecification来支持组合逻辑。这里以AndSpecification为例：

// 文件路径：SpecificationPattern/AndSpecification.cs using System.Linq.Expressions; namespace EfCoreSpecificationDemo.SpecificationPattern; public class AndSpecification<T> : Specification<T> { private readonly Specification<T> _left; private readonly Specification<T> _right; public AndSpecification(Specification<T> left, Specification<T> right) { _left = left; _right = right; } // 关键：使用 Expression.AndAlso 将两个条件表达式合并 public override Expression<Func<T, bool>> Criteria { get { var leftExpr = _left.Criteria; var rightExpr = _right.Criteria; var param = Expression.Parameter(typeof(T), "x"); var combinedBody = Expression.AndAlso( Expression.Invoke(leftExpr, param), Expression.Invoke(rightExpr, param) ); return Expression.Lambda<Func<T, bool>>(combinedBody, param); } } // 合并两个规约的 Includes 列表 public override List<Expression<Func<T, object>>> Includes { get { var includes = new List<Expression<Func<T, object>>>(); includes.AddRange(_left.Includes); includes.AddRange(_right.Includes); // 简单去重（根据表达式字符串，实际项目可能需要更复杂的比较） return includes.DistinctBy(exp => exp.ToString()).ToList(); } } }

OrSpecification和NotSpecification的实现类似，分别使用Expression.OrElse和Expression.Not。

4.4 定义泛型仓储接口与实现

现在，让我们定义一个支持规约的泛型仓储接口。

// 文件路径：Data/IRepository.cs using EfCoreSpecificationDemo.SpecificationPattern; namespace EfCoreSpecificationDemo.Data; public interface IRepository<T> where T : class { Task<T?> GetByIdAsync(int id); Task<IReadOnlyList<T>> GetAllAsync(); // 核心方法：根据规约查询 Task<IReadOnlyList<T>> FindAsync(ISpecification<T> specification); // 计数 Task<int> CountAsync(ISpecification<T> specification); // 添加与保存 Task<T> AddAsync(T entity); Task UpdateAsync(T entity); Task DeleteAsync(T entity); Task SaveChangesAsync(); }

其基于 EF Core 的实现：

// 文件路径：Data/EfRepository.cs using EfCoreSpecificationDemo.SpecificationPattern; using Microsoft.EntityFrameworkCore; namespace EfCoreSpecificationDemo.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?> GetByIdAsync(int id) => await _dbSet.FindAsync(id); public virtual async Task<IReadOnlyList<T>> GetAllAsync() => await _dbSet.ToListAsync(); public virtual async Task<IReadOnlyList<T>> FindAsync(ISpecification<T> specification) { // 应用规约，然后执行查询 var query = specification.Apply(_dbSet.AsQueryable()); return await query.ToListAsync(); } public virtual async Task<int> CountAsync(ISpecification<T> specification) { var query = specification.Apply(_dbSet.AsQueryable()); return await query.CountAsync(); } public async Task<T> AddAsync(T entity) { await _dbSet.AddAsync(entity); return entity; } public Task UpdateAsync(T entity) { _dbContext.Entry(entity).State = EntityState.Modified; return Task.CompletedTask; } public Task DeleteAsync(T entity) { _dbSet.Remove(entity); return Task.CompletedTask; } public async Task SaveChangesAsync() => await _dbContext.SaveChangesAsync(); }

注意FindAsync方法，它接收一个ISpecification<T>，调用其Apply方法构建查询，然后异步执行。这是连接规约模式和 EF Core 的桥梁。

5. 完整示例与代码实现

让我们用一个完整的博客系统示例来演示如何使用上述架构。假设我们有Blog和Post两个实体。

5.1 定义实体与 DbContext

// 文件路径：Entities/Blog.cs namespace EfCoreSpecificationDemo.Entities; public class Blog { public int Id { get; set; } public string Name { get; set; } = string.Empty; public string Url { get; set; } = string.Empty; public bool IsActive { get; set; } = true; public DateTime CreatedOn { get; set; } = DateTime.UtcNow; // 导航属性 public virtual ICollection<Post> Posts { get; set; } = new List<Post>(); }

// 文件路径：Entities/Post.cs namespace EfCoreSpecificationDemo.Entities; public class Post { public int Id { get; set; } public string Title { get; set; } = string.Empty; public string Content { get; set; } = string.Empty; public bool IsPublished { get; set; } public bool IsDeleted { get; set; } public DateTime? PublishedDate { get; set; } public int ViewCount { get; set; } public DateTime CreatedOn { get; set; } = DateTime.UtcNow; // 外键与导航属性 public int BlogId { get; set; } public virtual Blog Blog { get; set; } = null!; }

// 文件路径：Data/AppDbContext.cs using EfCoreSpecificationDemo.Entities; using Microsoft.EntityFrameworkCore; namespace EfCoreSpecificationDemo.Data; public class AppDbContext : DbContext { public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { } public DbSet<Blog> Blogs => Set<Blog>(); public DbSet<Post> Posts => Set<Post>(); protected override void OnModelCreating(ModelBuilder modelBuilder) { // 可以在这里配置一些实体关系或索引 modelBuilder.Entity<Post>() .HasQueryFilter(p => !p.IsDeleted); // 全局查询过滤器，自动过滤已删除的帖子 } }

5.2 创建具体的规约

现在，创建几个针对Post实体的规约。

// 文件路径：Specifications/PublishedPostsSpecification.cs using EfCoreSpecificationDemo.Entities; using EfCoreSpecificationDemo.SpecificationPattern; namespace EfCoreSpecificationDemo.Specifications; public class PublishedPostsSpecification : Specification<Post> { public PublishedPostsSpecification() { // 只查询已发布的文章 } public override Expression<Func<Post, bool>> Criteria => p => p.IsPublished; }

// 文件路径：Specifications/RecentPostsSpecification.cs using EfCoreSpecificationDemo.Entities; using EfCoreSpecificationDemo.SpecificationPattern; namespace EfCoreSpecificationDemo.Specifications; public class RecentPostsSpecification : Specification<Post> { private readonly int _days; public RecentPostsSpecification(int days = 7) { _days = days; // 按发布日期倒序排列 ApplyOrderByDescending(p => p.PublishedDate); } public override Expression<Func<Post, bool>> Criteria => p => p.PublishedDate.HasValue && p.PublishedDate.Value >= DateTime.UtcNow.AddDays(-_days); }

// 文件路径：Specifications/PostsWithBlogSpecification.cs using EfCoreSpecificationDemo.Entities; using EfCoreSpecificationDemo.SpecificationPattern; namespace EfCoreSpecificationDemo.Specifications; public class PostsWithBlogSpecification : Specification<Post> { public PostsWithBlogSpecification() { // 包含关联的 Blog 数据（Eager Loading） AddInclude(p => p.Blog); } // 此规约没有额外的过滤条件，查询所有 public override Expression<Func<Post, bool>> Criteria => p => true; }

5.3 在服务层中使用规约

创建一个服务类来协调这些规约和仓储。

// 文件路径：Services/PostService.cs using EfCoreSpecificationDemo.Data; using EfCoreSpecificationDemo.Entities; using EfCoreSpecificationDemo.Specifications; namespace EfCoreSpecificationDemo.Services; public class PostService { private readonly IRepository<Post> _postRepository; public PostService(IRepository<Post> postRepository) { _postRepository = postRepository; } // 场景1：获取最近一周已发布的文章，并包含博客信息 public async Task<IReadOnlyList<Post>> GetRecentPublishedPostsAsync() { // 组合规约：最近发布的 AND 已发布的 AND 包含博客信息 var spec = new RecentPostsSpecification(7) .And(new PublishedPostsSpecification()) .And(new PostsWithBlogSpecification()); // 注意：组合时 Includes 会被合并 return await _postRepository.FindAsync(spec); } // 场景2：获取某个博客下所有已发布文章（分页） public async Task<IReadOnlyList<Post>> GetPublishedPostsByBlogAsync(int blogId, int pageIndex, int pageSize) { // 创建一个新的组合规约 var spec = new PublishedPostsSpecification() .And(new PostsFromBlogSpecification(blogId)) // 假设有这个规约 .And(new PostsWithBlogSpecification()); // 动态添加分页（注意：我们的基类需要扩展以支持动态设置分页，或创建新的规约） // 更佳实践：创建一个 PagedSpecification 或使用构建器模式。 // 此处为演示，我们创建一个新的继承类来设置分页。 var pagedSpec = new PagedSpecification<Post>(spec, pageIndex * pageSize, pageSize); return await _postRepository.FindAsync(pagedSpec); } // 场景3：统计活跃博客的数量（博客下有至少一篇最近一个月发布的文章） public async Task<int> CountActiveBlogsAsync() { // 这里需要关联查询，更复杂的规约可能涉及子查询或特定仓储方法。 // 为简化演示，我们假设有一个 BlogRepository 和对应的规约。 // 这展示了规约模式的边界：对于非常复杂的跨实体聚合查询，可能需要专门的查询对象或仓储方法。 throw new NotImplementedException("此示例略过复杂关联统计的实现。"); } } // 辅助规约：分页规约 public class PagedSpecification<T> : Specification<T> { public PagedSpecification(Specification<T> innerSpec, int skip, int take) { // 这里需要“继承”innerSpec的所有条件、包含和排序。 // 一种实现方式是使用组合而非继承，或者修改基类以支持更灵活的构建。 // 这是一个高级话题，提示我们基础实现可能需要改进。 } // ... 具体实现需要考虑如何复制另一个规约的表达式树，较为复杂。 }

5.4 在 Program.cs 中集成与运行

// 文件路径：Program.cs using EfCoreSpecificationDemo.Data; using EfCoreSpecificationDemo.Entities; using EfCoreSpecificationDemo.Services; using Microsoft.EntityFrameworkCore; using Microsoft.Extensions.DependencyInjection; var services = new ServiceCollection(); // 1. 配置 DbContext (使用 SQLite 内存数据库方便演示) services.AddDbContext<AppDbContext>(options => options.UseSqlite("Data Source=:memory:")); // 2. 注册泛型仓储 services.AddScoped(typeof(IRepository<>), typeof(EfRepository<>)); // 3. 注册服务 services.AddScoped<PostService>(); var serviceProvider = services.BuildServiceProvider(); // 确保数据库创建并填充种子数据 using (var scope = serviceProvider.CreateScope()) { var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>(); await dbContext.Database.EnsureCreatedAsync(); await SeedDataAsync(dbContext); // 假设有一个填充测试数据的方法 } // 使用服务 using (var scope = serviceProvider.CreateScope()) { var postService = scope.ServiceProvider.GetRequiredService<PostService>(); var recentPosts = await postService.GetRecentPublishedPostsAsync(); Console.WriteLine($"找到 {recentPosts.Count} 篇近期发布的文章。"); foreach (var post in recentPosts) { Console.WriteLine($"- {post.Title} (来自博客: {post.Blog?.Name})"); } } async Task SeedDataAsync(AppDbContext context) { if (!await context.Blogs.AnyAsync()) { var blog = new Blog { Name = "技术博客", Url = "https://tech.example.com", IsActive = true }; context.Blogs.Add(blog); await context.SaveChangesAsync(); var posts = new List<Post> { new Post { Title = "EF Core 入门", Content = "...", IsPublished = true, PublishedDate = DateTime.UtcNow.AddDays(-1), BlogId = blog.Id }, new Post { Title = "规范模式详解", Content = "...", IsPublished = true, PublishedDate = DateTime.UtcNow.AddDays(-5), BlogId = blog.Id }, new Post { Title = "未发布的草稿", Content = "...", IsPublished = false, BlogId = blog.Id }, }; context.Posts.AddRange(posts); await context.SaveChangesAsync(); } }

6. 运行结果与效果验证

运行上述控制台程序，预期输出如下：

找到 2 篇近期发布的文章。 - EF Core 入门 (来自博客: 技术博客) - 规范模式详解 (来自博客: 技术博客)

如何验证规约生效？

1. 日志验证：在DbContext配置中启用敏感数据日志，可以查看生成的 SQL。你会看到类似这样的语句：

   SELECT p.*, b.* FROM Posts AS p INNER JOIN Blogs AS b ON p.BlogId = b.Id WHERE p.IsPublished = 1 AND p.PublishedDate >= @__startDate_0 ORDER BY p.PublishedDate DESC

   这表明IsPublished条件、PublishedDate条件、JOIN和ORDER BY都被正确应用了。
2. 单元测试：你可以为每个Specification编写单元测试，验证其Criteria表达式树是否正确。也可以为FindAsync方法编写集成测试，使用内存数据库验证返回的数据是否符合预期。

7. 常见问题与排查思路

8. 最佳实践与工程建议

1. 规约的单一职责：每个规约类应只代表一个明确的、可命名的业务规则，如ActiveUsersSpecification、OrdersFromLastMonthSpecification。避免创建“万能”规约。

2. 使用构建器模式增强灵活性：对于需要动态配置的规约（如分页参数、排序字段），可以考虑使用构建器模式（Fluent API）来创建规约，使代码更清晰。

   var spec = new PostSpecificationBuilder() .PublishedOnly() .FromBlog(blogId) .IncludeBlog() .OrderByDescending(p => p.PublishedDate) .Paginate(pageIndex, pageSize) .Build();

3. 支持投影（Select）：为了优化性能，经常只需要实体的部分字段。可以扩展规约模式，支持定义Select表达式，让仓储返回IQueryable<ProjectionType>或IEnumerable<ProjectionType>。

4. 规约的单元测试：规约的核心是表达式树。你可以轻松地为规约编写单元测试，验证其Criteria是否正确。使用内存中的对象列表（如List<Post>）和AsQueryable()进行测试，无需数据库。

5. 与 CQRS 结合：在更复杂的系统中，可以考虑将规约模式与命令查询职责分离（CQRS）架构结合。规约专门用于构建查询端（Read Side）的复杂查询，使查询模型更加专注和高效。

6. 谨慎使用组合：虽然And、Or、Not组合很强大，但过度组合可能导致表达式树非常复杂，影响 SQL 生成效率和可读性。对于固定的、常用的查询组合，可以考虑创建新的、命名的规约类。

7. 依赖注入：规约类通常是无状态的，只包含表达式树定义。它们一般不需要依赖注入，可以直接new出来。仓储和服务层才需要被注入。

8. 版本控制与演化：当业务规则变化时，你只需要修改对应的规约类。例如，“有效用户”的定义从“已激活”变为“已激活且邮箱已验证”，你只需修改ActiveUserSpecification.Criteria。所有使用该规约的查询都会自动更新。

通过遵循这些实践，规范模式就能成为你 EF Core 项目数据访问层的坚实支柱，显著提升代码的整洁度、可维护性和可测试性。它不仅仅是一种技术实现，更是一种让查询逻辑变得清晰、可组合和可管理的设计思想。