StarWars EF Core数据访问详解：StarWarsContext关系建模与数据库自动种子数据

StarWars EF Core数据访问详解：StarWarsContext关系建模与数据库自动种子数据

【免费下载链接】StarWarsGraphQL 'Star Wars' example using GraphQL for .NET, ASP.NET Core, Entity Framework Core项目地址: https://gitcode.com/gh_mirrors/st/StarWars

StarWars 是一个基于 GraphQL for .NET、ASP.NET Core 与 Entity Framework Core 的经典示例项目，它的核心演示了如何用 EF Core 完成完整的数据访问：通过StarWarsContext关系建模整个《星球大战》数据库，并在应用启动时自动注入种子数据。本文将带你快速理解这两大机制的实现细节。

🗂️ 项目分层：数据流是怎么走的？

项目采用三层架构，数据访问是其中最关键的一环：

核心层定义了纯领域模型，如 Character.cs、Human.cs、Droid.cs，而数据层负责把它们映射为真实的数据库表——两者完全解耦。

🎯 StarWarsContext：数据访问的统一入口

StarWarsContext.cs 是继承自DbContext的数据访问上下文，它通过8 个DbSet集合暴露了数据库的全部实体：

• Episodes/Planets/Characters：剧集、星球、角色
• Droids/Humans：机器人与人类（均为Character的子类）
• CharacterFriends/CharacterEpisodes：两个"连接表"实体，用于建模多对多关系

值得注意的双构造函数设计（第 13-22 行）：

• 参数化构造：注入DbContextOptions与ILogger，由 ASP.NET Core 依赖注入容器调用，是生产环境的主入口；
• 无参构造：直接硬编码 LocalDB 连接字符串（第 28 行），方便开发调试时独立创建上下文。

而连接字符串的真正"生产"来源在 Startup.cs：测试环境使用内存数据库UseInMemoryDatabase，正式环境则读取appsettings.json中的ConnectionStrings:StarWarsDatabaseConnection。这让同一个上下文既能跑集成测试、又能连真实 SQL Server。

🔗 关系建模全解析：OnModelCreating 中的 4 种关系

EF Core 建模的核心在OnModelCreating方法中（StarWarsContext.cs 第 34-83 行）。它用**流畅 API（Fluent API）**显式声明了 4 类关系，这正是初学者最常遇到的建模场景。

1. 显式主键 + 关闭自增

modelBuilder.Entity<Episode>().HasKey(c => c.Id); modelBuilder.Entity<Episode>().Property(e => e.Id).ValueGeneratedNever();

Episode、Planet、Character的主键都设置为ValueGeneratedNever()（第 40-49 行）——即主键不由数据库生成，必须由应用提供。种子数据正是借此手动指定了Id = 4/5/6、Id = 1/2等业务语义编号，避免了自增序列与业务编号不一致的尴尬。

2. 多对多关系：复合主键连接表

这是 EF Core 关系建模中最经典的部分。"角色 ↔ 角色"的朋友关系、"角色 ↔ 剧集"的出演关系，都通过独立的连接实体实现：

• CharacterFriend.cs：含CharacterId+FriendId两个外键
• CharacterEpisode.cs：含CharacterId+EpisodeId两个外键

建模时（第 52-64 行）：

1. 复合主键：HasKey(t => new { t.CharacterId, t.FriendId })，两列组合唯一，天然防止重复建"友谊"；
2. 双向导航：HasOne(cf => cf.Character).WithMany(c => c.CharacterFriends)，从任一角色都能找到它的所有朋友，反向也能找到谁把它列为朋友；
3. 删除限制：OnDelete(DeleteBehavior.Restrict)确保角色存在朋友关系时无法被删除，保护数据完整性。

3. 一对多关系：人类与故乡星球

modelBuilder.Entity<Human>().HasOne(h => h.HomePlanet).WithMany(p => p.Humans);

一行代码（第 82 行）建立了Human → Planet的一对多关系：一个星球（如 Tatooine）对应多位人类居民，每位人类只有一个故乡星球。EF Core 会自动在Humans表上生成HomePlanetId外键列。

4. 一"多"对一：剧集的英雄

Episode模型上有一个Hero导航属性（Episode.cs 第 10 行），指向某位Character——"这一部的英雄是谁"。这条外键正是通过第三次数据库迁移 Hero.cs 添加的：在Episodes表上新增可空的HeroId列并建立索引，删除行为同样是Restrict。

🌱 自动种子数据：启动即有数据

数据库建好了，第一次运行就需要满库数据。StarWars 的答案是把种子逻辑封装为扩展方法 StarWarsSeedData.cs 中的EnsureSeedData(this StarWarsContext db)，并在 Startup.cs 第 77 行 的Configure管道中一行调用db.EnsureSeedData()——应用每次启动都会检查并按需补种，无需手动执行任何脚本。

种子数据包含什么？🚀

其中藏着两个值得学习的工程细节：

① 幂等性设计：每个实体类别写入前都先判断if (!db.Episodes.Any())，表里已有数据就跳过。这保证了种子逻辑可以随每次启动安全执行，不会重复插入、不会报错。

② 严格的外键依赖顺序：必须先有剧集、星球，才能给人类挂上CharacterEpisodes与HomePlanet；先有全部角色，才能建立"朋友"关系；最后才指定剧集英雄（第 215-220 行）。顺序颠倒就会触发外键约束异常。

③ 全程日志可观测：_logger.LogInformation("Seeding episodes")等日志（第 12 行）让控制台清晰打印每一步种子进度，排查问题一目了然。

📦 迁移机制：Schema 如何演进

数据层的Migrations目录保存了 3 次结构变更的完整历史：

1. 20170215075510_Inital.cs——初始建库（基础表）；
2. 20170305213221_Full.cs——扩展为完整数据库（剧集/角色/关系表）；
3. 20170322183920_Hero.cs——为Episodes表添加HeroId外键。

每个迁移都实现了Up/Down双向操作，可随时升级或回滚，这正是 EF Core 迁移优于EnsureCreated的地方：结构变更可版本化、可审计、可协作。

✅ 总结：从 StarWars 学到的 4 个 EF Core 要点

1. 流畅 API 建模：在OnModelCreating中显式声明主键、复合主键、双向导航与删除行为，比依赖约定更可控；
2. 多对多 = 连接实体：用带复合主键的连接表（如CharacterFriend）建模，EF Core 自动处理外键与级联规则；
3. 种子数据 = 幂等扩展方法 + 启动时调用：EnsureSeedData让数据库"开箱即用"，且重复执行安全；
4. 迁移 + 环境分支：迁移管理 Schema 演进，Test环境切内存库，让同一套数据访问代码同时支撑开发与测试。

掌握了这套模式，你就能在任何 ASP.NET Core 项目中快速搭起结构清晰、自动初始化的 EF Core 数据访问层。🎉

【免费下载链接】StarWarsGraphQL 'Star Wars' example using GraphQL for .NET, ASP.NET Core, Entity Framework Core项目地址: https://gitcode.com/gh_mirrors/st/StarWars