1. 项目概述为什么EF是.NET开发者的必修课如果你刚开始接触.NET开发或者从ADO.NET、Dapper这类“手动挡”ORM转过来第一次听到Entity FrameworkEF这个名字可能会有点懵。这玩意儿到底是啥简单说EF是微软官方出品的一个对象关系映射ORM框架。它的核心任务就是帮你把数据库里那些冷冰冰的表和行变成你代码里活生生的类和对象。我刚开始用EF的时候也犯过嘀咕直接用SQL写查询不香吗为什么要多学一层框架但踩过几次坑之后我彻底明白了。当你面对一个拥有几十张表、复杂关联的业务系统时手动拼接SQL字符串、处理参数化查询、将DataReader的结果一行行映射到对象属性上……这些工作不仅繁琐而且极易出错代码维护起来简直就是噩梦。EF的价值就在于它把这套脏活累活全包了。你只需要用C#写写LINQ查询定义好实体类EF就能在背后帮你生成SQL、执行命令、管理连接并把结果自动填充到你的对象里。开发效率的提升不是一点半点。EF特别适合这几类场景一是快速原型开发你脑子里有个业务模型用Code First方式几分钟就能把数据库建起来二是中大型业务系统表结构复杂、关联多EF的导航属性能让关联查询变得异常清晰三是团队协作项目统一的ORM框架能极大降低沟通成本避免“SQL方言”满天飞。当然它也不是银弹。对于极致性能要求、需要高度定制化SQL的复杂报表查询或者存量存储过程特别多的老系统你可能需要搭配Dapper这样的微型ORM或者直接使用EF Core的原始SQL功能。但无论如何掌握EF是每一位现代.NET后端开发者构建数据访问层最基础、最核心的技能之一说它是必修课毫不为过。2. EF核心架构与三种开发模式解析要玩转EF首先得搞清楚它的“工作模式”。EF主要提供了三种开发模式每种模式思路不同适用场景也不同。选对了模式事半功倍选错了可能步步维艰。2.1 Database First从现有数据库出发如果你的项目已经有一个设计好的数据库或者你需要对接一个遗留系统那么Database First数据库优先可能是最直接的入门方式。它的工作流是数据库已经存在 - 使用Visual Studio的“ADO.NET实体数据模型”向导反向工程生成实体类.cs文件和上下文DbContext- 在代码中操作这些生成的类。这么做的最大好处是“稳”。你的代码模型严格遵循数据库结构几乎不会出现模型与数据库不同步的问题。对于数据库主导的项目或者DBA权力比较大的团队这种模式很受欢迎。但是它的缺点也很明显生成的实体类代码通常比较“胖”里面充满了EF的特性标签如[Key],[ForeignKey]而且一旦数据库表结构发生变化你需要更新这个EDMX模型或使用Scaffold-DbContext命令重新生成这可能会覆盖你手写的一些自定义逻辑。所以Database First模式更像是一种“对接”和“迁移”策略适合快速起步但长期来看对代码的控制力较弱。2.2 Model First在可视化设计中建模Model First模型优先模式现在用得相对少了但在某些场景下仍有其价值。你不需要先有数据库而是在Visual Studio的设计器里用拖拽的方式画出一个实体关系图ER图。设计器帮你生成实体类的代码同时也能根据这个模型生成创建数据库的SQL脚本。这种模式非常直观尤其适合那些对数据库SQL不熟但熟悉UML或类图的设计者。你可以专注于业务实体的定义和它们之间的关系而不用操心具体的表字段类型。然而它的灵活性是三种模式中最差的。一旦模型复杂起来设计器可能变得难以维护而且从模型同步到数据库的过程有时会丢失一些数据库特有的优化设置。对于追求代码即设计、版本控制友好的现代开发流程来说Model First显得有点笨重。2.3 Code First以代码定义一切的现代方式这是目前EF社区最主流、也是最推荐的方式尤其是EF Core几乎完全围绕此模式构建。Code First代码优先的核心思想是你的领域模型实体类就是唯一的真相来源。你先用纯C#代码定义实体类及其关系然后通过EF的迁移Migration功能将这些模型变化同步到数据库。举个例子你想定义一个博客Blog和文章Post的模型public class Blog { public int BlogId { get; set; } public string Url { get; set; } // 导航属性一个博客有多篇文章 public ListPost Posts { get; set; } } public class Post { public int PostId { get; set; } public string Title { get; set; } public string Content { get; set; } // 外键属性可省略EF能推断 public int BlogId { get; set; } // 导航属性一篇文章属于一个博客 public Blog Blog { get; set; } }然后你定义一个继承自DbContext的类public class BloggingContext : DbContext { public DbSetBlog Blogs { get; set; } public DbSetPost Posts { get; set; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { // 配置连接字符串这里用SQLite示例 optionsBuilder.UseSqlite(Data Sourceblogging.db); } }接下来在程序包管理器控制台执行两个命令Add-Migration InitialCreate Update-DatabaseEF Core就会检查你的模型生成名为“InitialCreate”的迁移文件里面是C#代码描述了要进行的数据库操作然后执行这个迁移在数据库中创建Blogs和Posts两张表并建立外键关系。Code First的优势是巨大的完全的控制权模型是干净的POCO类、优秀的版本控制迁移文件是C#代码可以像其他代码一样签入Git、持续集成/交付友好迁移可以自动化执行。它代表了“基础设施即代码”的思想在数据层的实践。对于新项目我强烈建议直接从Code First开始。它需要你理解一些约定如Id或[类名]Id属性会被默认设为主键但一旦掌握你会爱上这种开发体验。注意选择哪种模式不是技术优劣问题更多的是项目上下文和团队习惯问题。但对于新手我建议的学习路径是先用Code First写个小demo理解实体、上下文、迁移的核心概念然后再去了解Database First知道如何与现有数据库协作。这样你能建立起最完整的概念体系。3. 核心组件深度拆解DbContext与DbSet理解了模式我们深入到EF的核心运行时组件。如果把EF比作一个工厂那么DbContext就是厂长DbSetT就是各个生产车间。3.1 DbContext数据操作的指挥中心DbContext是你与数据库交互的主要入口。它不仅仅是一个数据库连接的包装更是一个功能强大的工作单元Unit of Work和变更跟踪器Change Tracker的结合体。工作单元模式这意味着你在一个DbContext实例的生命周期内通常是一个Web请求进行的多次增删改查操作会被集中管理。只有当你调用SaveChanges()或SaveChangesAsync()时所有这些变更才会被一次性、以事务的方式提交到数据库。这保证了数据的一致性。比如你先后添加了一个用户和一条该用户的订单记录如果中间某步出错整个SaveChanges操作会回滚不会出现用户创建了订单却没记录的情况。变更跟踪这是EF的魔法之一。当你从数据库查询出一个实体对象后DbContext会记住这个对象最初的状态。之后你在代码中修改了这个对象的属性。当你调用SaveChanges时EF的变更跟踪器会对比当前状态和原始状态自动生成只更新那些被修改过的字段的SQL语句。你不需要手动写UPDATE ... SET Name新值 WHERE Id1EF帮你高效地完成了。配置与连接管理DbContext也负责配置数据库提供程序SQL Server、SQLite、PostgreSQL等、连接字符串以及定义模型的高级配置通过OnModelCreating方法。一个典型的上下文配置如下public class AppDbContext : DbContext { public AppDbContext(DbContextOptionsAppDbContext options) : base(options) // 依赖注入推荐方式 { } public DbSetUser Users { get; set; } public DbSetOrder Orders { get; set; } protected override void OnModelCreating(ModelBuilder modelBuilder) { // 在这里进行Fluent API配置例如定义复合主键、索引等 modelBuilder.EntityUser() .HasIndex(u u.Email) .IsUnique(); // 为Email字段创建唯一索引 } }在ASP.NET Core中我们通常会在Startup.cs或Program.cs中通过依赖注入来配置和获取DbContext这能更好地管理其生命周期默认为Scoped即一次请求一个实例。3.2 DbSet 实体集合的抽象DbSetT代表了数据库中特定表的抽象。你可以把它看作是一个内存中的集合但它的背后是数据库。通过DbSetT你可以执行所有的CRUD操作。查询QueryDbSetT实现了IQueryableT这是LINQ to Entities的基石。当你写context.Users.Where(u u.Age 18)时你得到的是一个IQueryableUser对象。这个查询还没有执行它只是一个表达式树。EF会在你需要结果的时候例如调用.ToList()、.FirstOrDefault()或foreach遍历时才将这颗表达式树翻译成SQL发送到数据库执行。这种“延迟执行”机制非常高效允许你动态构建复杂的查询。添加Addcontext.Users.Add(newUser)将一个新实体标记为“Added”状态。此时它只在内存的变更跟踪器中数据库里还没有。直到SaveChanges被调用INSERT语句才会生成并执行。更新Update对于已跟踪的实体比如刚从数据库查出来的直接修改其属性即可。对于未跟踪的实体比如从HTTP请求反序列化出来的你需要调用context.Users.Update(existingUser)来将其附加到上下文并标记为“Modified”状态。删除Removecontext.Users.Remove(user)将实体标记为“Deleted”状态。关于DbSet的一个关键理解DbSet并不包含所有数据。context.Users本身不代表“Users表中的所有行”它代表的是一个“针对Users表的查询入口”。当你执行context.Users.ToList()才是真的把所有数据取到内存。在Web应用中一定要避免不经筛选就直接ToList()大表这会导致全表扫描性能灾难。正确的做法是始终先通过Where、Take、Skip等操作在数据库端完成过滤和分页。4. 数据建模与关系配置实战定义好实体类只是第一步如何精确地描述它们之间的关系和约束才是建模的核心。EF主要通过两种方式来配置模型数据注解Data Annotations和Fluent API。4.1 数据注解声明式的简单配置数据注解是以特性Attribute的方式直接标注在实体类的属性上。这种方式非常直观适合简单的配置。using System.ComponentModel.DataAnnotations; using System.ComponentModel.DataAnnotations.Schema; public class Book { [Key] // 显式指定主键 public int BookId { get; set; } [Required] // 非空约束 [MaxLength(100)] // 最大长度 public string Title { get; set; } [Column(TypeName decimal(18, 2))] // 指定数据库列类型 public decimal Price { get; set; } [ForeignKey(AuthorId)] // 指定外键属性名 public int AuthorId { get; set; } [ForeignKey(AuthorId)] public Author Author { get; set; } // 导航属性 }数据注解的优点是清晰、集中一眼就能看到这个属性的所有约束。但它也有局限一是配置分散在各个实体类中对于复杂的模型关系查看起来不够整体二是有些高级配置如复合键、继承映射、并发令牌等用数据注解无法实现或非常别扭。4.2 Fluent API强大而灵活的流式配置Fluent API在DbContext的OnModelCreating方法中配置。它功能更强大是进行复杂、精细模型配置的首选方式。protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.EntityBook(entity { // 配置主键 entity.HasKey(e e.BookId); // 配置属性 entity.Property(e e.Title) .IsRequired() .HasMaxLength(100); entity.Property(e e.Price) .HasColumnType(decimal(18, 2)); // 配置一对一关系 entity.HasOne(e e.Author) .WithMany(a a.Books) // 假设Author有ICollectionBook Books属性 .HasForeignKey(e e.AuthorId) .OnDelete(DeleteBehavior.Cascade); // 级联删除作者删了书也全删 // 配置索引 entity.HasIndex(e e.Title); entity.HasIndex(e new { e.AuthorId, e.PublishedDate }); // 复合索引 }); // 配置多对多关系EF Core 5.0 modelBuilder.EntityBook() .HasMany(b b.Tags) .WithMany(t t.Books) .UsingEntity(j j.ToTable(BookTags)); // 指定连接表名 }Fluent API就像在编写数据库的Schema定义但用的是C#语法。它能实现所有数据注解的功能并且更多比如精确控制级联删除行为Restrict拒绝删除、Cascade级联删除、SetNull设为空等。配置继承映射策略TPH每层次结构一张表、TPT每类型一张表、TPC每具体类一张表。配置并发控制使用IsConcurrencyToken()配置行版本或时间戳字段防止更新冲突。配置值对象Owned Entity Types将某个复杂类型映射到主实体的同一张表中。我的经验是对于简单的字段约束如[Required],[MaxLength]用数据注解很方便。但对于关系配置和任何复杂的、影响数据库Schema的配置一律使用Fluent API。这样所有配置都集中在OnModelCreating这一个地方维护和查阅起来一目了然更像一份正式的“数据契约”。4.3 关系映射的陷阱与最佳实践定义关系时有几个坑新手很容易掉进去循环引用与序列化如果Author有Books集合Book又有Author导航属性在通过Web API返回JSON时序列化器如Newtonsoft.Json或System.Text.Json可能会陷入无限循环。解决方案是在导航属性上添加[JsonIgnore]特性或者配置序列化选项忽略循环引用更优雅的方式是使用DTO数据传输对象来返回数据而不是直接返回实体。延迟加载与N1查询问题假设你遍历所有作者然后打印每个作者的所有书名var authors context.Authors.ToList(); foreach (var author in authors) { Console.WriteLine(${author.Name}写了); foreach (var book in author.Books) // 这里会触发延迟加载为每个作者单独发一次查询 { Console.WriteLine($ - {book.Title}); } }这会导致“N1查询问题”1次查询获取所有作者然后为每个作者再发起1次查询获取他的书。如果作者有100个就是101次查询性能极差。解决方案是使用显式加载Include或投影查询Select在第一次查询时就加载好关联数据// 方法1使用Include显式加载贪婪加载 var authorsWithBooks context.Authors .Include(a a.Books) .ToList(); // 方法2使用Select投影只取所需数据通常更高效 var authorInfo context.Authors .Select(a new { a.Name, BookTitles a.Books.Select(b b.Title).ToList() }) .ToList();外键属性是可选的但推荐显式定义EF Core可以通过约定推断出外键例如AuthorId但显式定义一个AuthorId属性会让你的代码意图更清晰并且在某些需要直接操作外键值的场景下比如批量更新更方便。5. LINQ查询与数据操作全指南EF的强大一半体现在它无缝集成了LINQ。你可以用写C#集合操作的方式来编写数据库查询。5.1 LINQ to Entities查询基础LINQ查询有两种语法查询表达式语法类似SQL和方法语法链式调用。方法语法更常用也更灵活。// 方法语法示例 var popularBooks context.Books .Where(b b.Price 50 b.PublishDate.Year 2020) .OrderByDescending(b b.Rating) .ThenBy(b b.Title) .Take(10) .ToList(); // 注意ToList()是触发查询执行的地方 // 等效的查询表达式语法 var popularBooks2 (from b in context.Books where b.Price 50 b.PublishDate.Year 2020 orderby b.Rating descending, b.Title select b).Take(10).ToList();关键点在于在调用ToList()、FirstOrDefault()、Count()、Any()等方法之前查询只是一个表达式树没有执行。这允许你动态构建查询IQueryableBook query context.Books; if (!string.IsNullOrEmpty(searchTitle)) { query query.Where(b b.Title.Contains(searchTitle)); } if (minPrice.HasValue) { query query.Where(b b.Price minPrice.Value); } var finalResult query.OrderBy(b b.Price).ToList();5.2 加载关联数据Include与ThenInclude如前所述使用Include来避免N1查询。// 加载单层关联 var blogs context.Blogs .Include(b b.Posts) // 加载Blog的Posts集合 .ToList(); // 加载多层关联嵌套的ThenInclude var blogsWithDetails context.Blogs .Include(b b.Posts) .ThenInclude(p p.Author) // 加载每篇Post的Author .Include(b b.Owner) // 加载Blog的Owner另一个导航属性 .ToList();Include是贪婪加载它会将关联的数据一次性通过JOIN查询出来。对于深层或大型关联要小心可能产生的巨大结果集和“笛卡尔积爆炸”问题。有时分多次查询使用Load方法或使用投影Select可能是更好的选择。5.3 增删改查与SaveChanges新增var newBlog new Blog { Url http://newblog.com }; context.Blogs.Add(newBlog); // 标记为Added // 或者 context.Add(newBlog); DbContext有非泛型Add方法 await context.SaveChangesAsync(); // 执行INSERTnewBlog的Id会被数据库自动填充更新var blog await context.Blogs.FindAsync(1); // 先查询出实体此时它被上下文跟踪 if (blog ! null) { blog.Url http://updated.com; // 直接修改属性 await context.SaveChangesAsync(); // 生成UPDATE语句只更新Url字段 }对于从MVC/API控制器接收的模型未被上下文跟踪你需要告诉EF这是更新// blogFromClient是从HTTP请求反序列化得到的对象有Id context.Blogs.Update(blogFromClient); // 标记整个实体为Modified // 或者更精细地操作 var existingBlog await context.Blogs.FindAsync(blogFromClient.BlogId); context.Entry(existingBlog).CurrentValues.SetValues(blogFromClient); // 只复制变化的属性 await context.SaveChangesAsync();删除var blog await context.Blogs.FindAsync(1); if (blog ! null) { context.Blogs.Remove(blog); await context.SaveChangesAsync(); } // 或者使用简化删除无需先查询但需确保实体状态正确 var blogToDelete new Blog { BlogId 1 }; context.Blogs.Attach(blogToDelete); context.Blogs.Remove(blogToDelete); await context.SaveChangesAsync();SaveChanges的工作原理当你调用它时EF的变更跟踪器会检查所有被跟踪的实体找出状态为Added、Modified、Deleted的实体。然后它为这些变更生成相应的INSERT、UPDATE、DELETE语句并在一个事务中执行它们。如果所有语句都成功事务提交如果任何一条失败事务回滚数据库保持原样并抛出异常。这保证了操作的原子性。5.4 原生SQL与存储过程虽然LINQ很强但有些复杂查询或性能关键路径你可能需要写原生SQL。EF Core提供了很好的支持。// 执行返回实体的查询 var blogs context.Blogs .FromSqlRaw(SELECT * FROM Blogs WHERE Rating {0}, 5) .ToList(); // 执行非查询命令增删改 var rowsAffected context.Database.ExecuteSqlRaw( UPDATE Blogs SET Rating Rating 1 WHERE BlogId {0}, blogId); // 调用存储过程查询 var blogsFromSp context.Blogs .FromSqlRaw(EXECUTE dbo.GetPopularBlogs minRating{0}, 5) .ToList();使用原生SQL时务必使用参数化查询像上面例子中用{0}占位符绝对不要用字符串拼接以防止SQL注入攻击。EF Core会将占位符转换为安全的参数化查询。6. 迁移Migration管理数据库的版本控制Code First模式的核心支柱就是迁移。迁移是一组按顺序应用的、使数据库架构与模型保持同步的指令。它就像是数据库的Git。6.1 迁移工作流创建迁移当你的实体类发生变化新增、修改、删除在程序包管理器控制台执行Add-Migration [迁移名称]例如Add-Migration AddBlogRating。EF Core会比较当前模型与上一次迁移时的模型快照生成一个迁移文件如20250101010101_AddBlogRating.cs里面包含Up和Down方法。Up方法描述如何将数据库升级到新版本Down方法描述如何回退到旧版本。检查迁移生成的迁移文件是C#代码你应该审查它特别是它生成的SQL操作是否符合预期。你可以使用Script-Migration命令生成SQL脚本而不执行。应用迁移Update-Database这个命令会将所有未应用的迁移应用到数据库。在开发环境这通常直接执行。在生产环境你应该使用生成的SQL脚本在可控的数据库部署流程中执行。回滚迁移如果最新迁移有问题可以回滚到上一个版本Update-Database [上一个迁移的名称]或者直接删除最新的迁移文件确保数据库已回滚或未应用然后重新创建。6.2 迁移的常见问题与技巧迁移文件冲突在团队开发中如果两个人同时添加了迁移可能会产生冲突。解决方法是先回滚本地未提交的迁移Update-Database到共同祖先拉取队友的迁移并应用然后重新添加自己的迁移。最好通过团队规范来避免同时添加迁移。自定义迁移SQL有时自动生成的迁移不够优化或者你需要执行一些特殊操作如初始化数据、创建复杂索引。你可以在Up方法中直接编写SQLprotected override void Up(MigrationBuilder migrationBuilder) { migrationBuilder.AddColumnint( name: Rating, table: Blogs, nullable: false, defaultValue: 0); // 自定义SQL为所有老博客设置一个初始评分 migrationBuilder.Sql(UPDATE Blogs SET Rating 5 WHERE CreatedDate 2024-01-01); }生产环境部署千万不要在生产服务器上直接运行Update-Database。应该使用Script-Migration -Idempotent命令生成一个幂等的SQL脚本。这个脚本包含了检查迁移是否已应用的逻辑可以安全地在CI/CD管道中或由DBA执行。敏感数据如连接字符串不要在迁移代码或DbContext配置中硬编码连接字符串。应该使用配置系统如appsettings.json和用户机密开发时或环境变量生产时来管理。7. 性能优化与常见陷阱规避EF用起来爽但用不好也容易成为性能瓶颈。下面是一些关键的优化点和避坑指南。7.1 查询性能优化只选择需要的字段投影这是最重要的优化原则。不要总是Select *。// 不好查询整个实体 var blogs context.Blogs.ToList(); // 好只查询需要的字段 var blogTitles context.Blogs.Select(b new { b.BlogId, b.Url }).ToList();投影查询返回的是匿名类型或DTO它们不会被变更跟踪内存占用小传输的数据量也少。警惕延迟加载在Web应用或服务中强烈建议显式关闭延迟加载。延迟加载会导致不可预知的数据库查询N1问题并且通常是在序列化响应时触发难以监控和调试。在DbContext配置中设置LazyLoadingEnabled false并强制自己使用Include或投影。分页分页再分页对于任何可能返回大量数据的查询必须分页。var pageNumber 1; var pageSize 20; var pagedBlogs context.Blogs .OrderBy(b b.BlogId) .Skip((pageNumber - 1) * pageSize) .Take(pageSize) .ToList();使用Skip和Take在数据库端完成分页而不是把所有数据取到内存再分片。使用异步方法为了不阻塞线程提高应用吞吐量尽量使用ToListAsync()、FirstOrDefaultAsync()、SaveChangesAsync()等异步方法。7.2 变更跟踪与上下文生命周期DbContext不是单例DbContext设计为轻量级、短生命周期的对象。在ASP.NET Core中默认注册为Scoped生命周期每个请求一个实例。绝对不要将其注册为Singleton否则变更跟踪器会积累大量实体导致内存泄漏和并发问题。适时使用AsNoTracking对于只读查询如果你确定后续不会修改这些实体并调用SaveChanges使用AsNoTracking可以显著提升查询性能因为EF不会为这些实体建立变更跟踪快照。var readOnlyBlogs context.Blogs.AsNoTracking().Where(b b.Rating 4).ToList();批量操作优化EF Core 7.0 对批量更新和删除提供了更好的支持ExecuteUpdate和ExecuteDelete它们会生成一条SQL语句而不是先查询再逐条操作。// 传统方式低效先查询再循环修改最后SaveChanges // var blogs context.Blogs.Where(b b.Rating 3).ToList(); // foreach(var b in blogs) b.Rating 3; // context.SaveChanges(); // 高效批量更新EF Core 7.0 await context.Blogs .Where(b b.Rating 3) .ExecuteUpdateAsync(setters setters.SetProperty(b b.Rating, 3)); // 高效批量删除 await context.Blogs .Where(b b.CreatedDate.Year 2020) .ExecuteDeleteAsync();对于大量数据的插入考虑使用DbContext的AddRange并合理设置SaveChanges的批次大小DbContextOptionsBuilder可以配置MaxBatchSize或者使用像SqlBulkCopy这样的专门工具。7.3 日志与监控打开EF Core的日志记录是了解其背后做了什么、发现性能问题的关键。// 在DbContext配置中启用简单日志开发环境 optionsBuilder.UseSqlServer(connectionString) .LogTo(Console.WriteLine, LogLevel.Information); // 将日志输出到控制台 // 或者在ASP.NET Core中使用ILogger optionsBuilder.UseSqlServer(connectionString) .LogTo((message) logger.LogInformation(message), LogLevel.Information);查看日志你可以看到EF生成的SQL语句、执行时间、参数等。特别注意那些“重复查询”和“查询了过多不必要字段”的日志。8. 实战构建一个简单的博客系统数据层让我们把上面的知识串起来快速构建一个博客系统的核心数据层。假设我们有Blog,Post,Comment,Tag实体。第一步定义实体public class Blog { public int BlogId { get; set; } [Required, MaxLength(200)] public string Url { get; set; } public int Rating { get; set; } 0; public DateTime CreatedDate { get; set; } DateTime.UtcNow; // 导航属性 public ListPost Posts { get; set; } new ListPost(); } public class Post { public int PostId { get; set; } [Required, MaxLength(500)] public string Title { get; set; } public string Content { get; set; } public DateTime PublishedDate { get; set; } public bool IsPublished { get; set; } public int BlogId { get; set; } public Blog Blog { get; set; } public ListComment Comments { get; set; } new ListComment(); public ListTag Tags { get; set; } new ListTag(); } public class Comment { public int CommentId { get; set; } public string Author { get; set; } public string Content { get; set; } public DateTime CreatedAt { get; set; } DateTime.UtcNow; public int PostId { get; set; } public Post Post { get; set; } } public class Tag { public int TagId { get; set; } [Required, MaxLength(50)] public string Name { get; set; } public ListPost Posts { get; set; } new ListPost(); }第二步配置DbContext和关系public class BloggingContext : DbContext { public BloggingContext(DbContextOptionsBloggingContext options) : base(options) { } public DbSetBlog Blogs { get; set; } public DbSetPost Posts { get; set; } public DbSetComment Comments { get; set; } public DbSetTag Tags { get; set; } protected override void OnModelCreating(ModelBuilder modelBuilder) { // Blog 配置 modelBuilder.EntityBlog(entity { entity.HasKey(e e.BlogId); entity.HasIndex(e e.Url).IsUnique(); entity.Property(e e.Url).IsRequired().HasMaxLength(200); }); // Post 配置 modelBuilder.EntityPost(entity { entity.HasKey(e e.PostId); entity.Property(e e.Title).IsRequired().HasMaxLength(500); entity.Property(e e.PublishedDate).HasDefaultValueSql(GETUTCDATE()); // SQL Server语法 // Post - Blog (多对一) entity.HasOne(p p.Blog) .WithMany(b b.Posts) .HasForeignKey(p p.BlogId) .OnDelete(DeleteBehavior.Cascade); // 博客删除文章也删除 // Post - Tags (多对多) entity.HasMany(p p.Tags) .WithMany(t t.Posts) .UsingEntity(j j.ToTable(PostTags)); }); // Comment 配置 modelBuilder.EntityComment(entity { entity.HasKey(e e.CommentId); // Comment - Post (多对一) entity.HasOne(c c.Post) .WithMany(p p.Comments) .HasForeignKey(c c.PostId) .OnDelete(DeleteBehavior.Cascade); // 文章删除评论也删除 }); // Tag 配置 modelBuilder.EntityTag(entity { entity.HasKey(e e.TagId); entity.HasIndex(e e.Name).IsUnique(); // 标签名唯一 entity.Property(e e.Name).IsRequired().HasMaxLength(50); }); } }第三步在Program.cs中注册服务var builder WebApplication.CreateBuilder(args); // 从配置中读取连接字符串 var connectionString builder.Configuration.GetConnectionString(DefaultConnection); // 注册DbContext使用SQL Server builder.Services.AddDbContextBloggingContext(options options.UseSqlServer(connectionString) .LogTo(Console.WriteLine, LogLevel.Information) // 开发时看SQL日志 ); var app builder.Build(); // ... 中间件配置 app.Run();第四步创建并应用初始迁移在程序包管理器控制台确保默认项目是你的数据层项目Add-Migration InitialCreate Update-Database第五步在服务中使用public class BlogService { private readonly BloggingContext _context; public BlogService(BloggingContext context) { _context context; } public async TaskListBlogSummaryDto GetPopularBlogsAsync(int topN) { // 使用投影查询只取所需数据避免N1 var blogs await _context.Blogs .Where(b b.Rating 3) .OrderByDescending(b b.Rating) .Take(topN) .Select(b new BlogSummaryDto { BlogId b.BlogId, Url b.Url, PostCount b.Posts.Count(p p.IsPublished) // 在数据库端计数 }) .AsNoTracking() // 只读不跟踪 .ToListAsync(); return blogs; } public async Task AddPostToBlogAsync(int blogId, CreatePostDto newPost) { // 假设newPost包含Title, Content, TagIds var post new Post { Title newPost.Title, Content newPost.Content, BlogId blogId, IsPublished true, PublishedDate DateTime.UtcNow }; // 处理多对多关系关联标签 if (newPost.TagIds?.Any() true) { var tags await _context.Tags .Where(t newPost.TagIds.Contains(t.TagId)) .ToListAsync(); post.Tags.AddRange(tags); } _context.Posts.Add(post); await _context.SaveChangesAsync(); } }这个简单的例子涵盖了实体定义、复杂关系配置一对多、多对多、Fluent API使用、依赖注入、查询优化投影、AsNoTracking以及服务层操作。从这里出发你可以根据业务需求不断增加新的实体和复杂的查询逻辑。记住EF是一个强大的工具但理解其原理和最佳实践才能让它真正为你的项目赋能而不是成为负担。