EF Core 模型提取实战指南从 DbContext 与迁移到 D2 数据库关系图【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读本文讲解如何从任意 Entity Framework CoreEF Core代码库中系统化地提取数据库模型——包括表、列、主外键、索引、拥有类型与多对多联接表——并据此生成可渲染为 SVG/PNG 的 D2 实体关系图。文中方法源自本仓库efcore-d2-db-diagram技能中的模型提取规范见 references/efcore-model-extraction.md读完你既能掌握一套可复用的「源码检查 → 模型归并 → 图谱产出」流程也能准确判断 EF Core 各配置来源发生冲突时该以谁为准。为什么需要「模型提取」这一步EF Core 的持久化模型并不等于 C# 类的原始形状表名可能被ToTable改写外键可能是未在实体中声明的影子属性多对多关系可能由约定隐式生成联接表值对象可能通过OwnsOne/OwnsMany以独立表或内联列的形式持久化。因此直接照着实体类的字段画图几乎必然与实际数据库结构产生偏差。模型提取的目的正是建立一个「规范化后的数据库模型normalized database model」以数据库表为第一等公民明确每张表的真实名称、主键、外键、必填/可选列、索引、约束与删除行为之后再进入 D2 生成阶段。这也是 SKILL.md 中工作流第 7 步「Build a normalized database model before writing D2」所强调的关键中间产物。检查顺序从哪里开始读代码提取模型时应按下述顺序逐层检查源码。顺序本身是有意义的——越靠前的文件越能反映最终持久化形态DbContext类确定实体集与配置入口。通常一个DbContext对应一个数据库或一个限界上下文是整张图的根。DbSetT声明列出所有可被查询的实体集合是「哪些类型持久化为表」的第一线索。OnModelCreatingFluent API 的主战场集中定义表名、键、索引、关系与删除行为。IEntityTypeConfigurationT类按实体拆分的配置类常配合ApplyConfigurationsFromAssembly使用是 Fluent API 的结构化组织形式。实体类Entity classes确认属性、导航属性与数据注解。迁移与模型快照Migrations model snapshot验证最终落库的实际表结构。数据注解Data annotations[Key]、[Required]、[MaxLength]、[Column]、[Table]等特性标注的声明式约束。这一顺序与本仓库中 SKILL.md 推荐工作流的前 6 步一致先定位DbContext与DbSetT再读实体与配置类最后用迁移核验。映射优先级来源冲突时以谁为准不同配置来源可能相互矛盾——例如实体上用[Required]标注了必填但 Fluent API 里IsRequired(false)覆盖了它又例如迁移快照中的表名与实体类命名不一致。此时必须按下述优先级裁决而不是凭直觉最新迁移 / 模型快照这是数据库的「既成事实」代表已经应用或将要应用的真实结构优先级最高。Fluent APIOnModelCreating与IEntityTypeConfigurationT程序化配置优先级次之。数据注解声明式配置再次之。EF Core 约定Conventions在没有任何显式配置时才生效的默认行为。C# 类形状class shape仅作为兜底参考例如类型推断、属性命名映射。这条优先级在 SKILL.md 的「Source Priority」一节中被原样强调当来源不一致时始终以最新迁移/快照为准其次是 Fluent API再次是数据注解、约定最后才是 C# 原始形态。需要识别的关键 EF Core API提取时应在全库范围内检索下列 API它们各自对应数据库模型中的一类要素API提取的信息ToTable实际表名ToTable(Table, schema)还指定数据库 schemaHasKey主键多个属性构成复合主键HasAlternateKey备用键唯一约束HasIndex索引定义配合IsUnique得到唯一索引IsUnique索引唯一性标志Property对某个属性做精细映射列名、类型、长度、转换等的入口HasColumnName列的实际名称区别于属性名HasColumnType数据库列类型如varchar(200)IsRequired列/关系是否必填非空HasMaxLength字符串列最大长度HasConversion值转换器如枚举 ↔ 字符串、复杂对象 ↔ JSON影响持久化类型HasOne/WithMany/WithOne关系两端的导航配置HasForeignKey外键属性或影子外键列OnDelete删除行为Cascade/Restrict/NoAction/SetNull/ClientSetNullOwnsOne/OwnsMany拥有类型值对象可内联列或独立表UsingEntity显式声明多对多联接表Ignore被忽略的属性或实体不持久化图上不应出现识别出上述 API 后还需同步记录影子属性仅在 Fluent API 中配置、实体中不存在的属性、值转换对列类型的影响、枚举属性的持久化形式以及被Ignore排除的部分——后者在画图时必须主动剔除。用迁移校验事实快照里的真实结构迁移Migrations是模型提取的「事实核查层」因为它是 EF Core 根据模型计算出的、最终将应用到数据库的操作序列。通过迁移文件及其ModelSnapshot可以确认实际表名与ToTable配置或约定命名核对。联接表join tables多对多隐式生成的表实体类中往往不存在对应类型。影子外键列shadow FK columns未声明为实体属性、仅存在于数据库中的外键列。索引包括唯一索引与复合索引。复合键由多个列构成的主键或备用键。删除行为外键约束的ON DELETE语义。仅存在于迁移中的表migration-only tables例如__EFMigrationsHistory这类由 EF Core 自身维护、与业务实体无关的表。从迁移中读取这些信息后再回到实体与 Fluent API 对照验证——这正是「映射优先级」把迁移快照列为最高依据的原因。本仓库的 SKILL.md 也明确规定迁移数据用于「confirm table names, join tables, indexes and delete behaviors」并推荐在每次重新生成图之前都重新读取映射与迁移避免模型过期。提取结果如何进入 D2 图关系与分组规则模型提取的产出要落到.d2文件中需要配合本技能的其他参考文档完成三件事1. 关系推断参照 references/relationship-rules.md 将提取到的导航与键信息归并为四类关系统一用「从依赖表指向主表」的有向边表达一对多1:N由HasOne(...).WithMany(...)、依赖方外键属性、主方集合导航识别渲染为Orders.ClientId - Clients.Id: N:1。一对一1:1由HasOne(...).WithOne(...)、唯一外键索引或共享主键关系识别渲染为ClientProfiles.ClientId - Clients.Id: 1:1。多对多N:N由UsingEntity、双向集合导航无显式联接实体或迁移中带两个外键与复合键的联接表识别默认显式渲染联接表。拥有类型owned由OwnsOne、OwnsMany、[Owned]识别默认内联展示除非检测到表拆分或独立表映射。可选关系外键可空、配置了IsRequired(false)或迁移列为可空时判定为可选图中用虚线边表示。2. 表与样式表达参照 references/d2-erd-style.md 使用sql_table形状与统一样式类Clients: { shape: sql_table Id: uuid {constraint: primary_key} Name: varchar(200) Status: enum }样式约定定义于 SKILL.md 的 Style Rules主实体表实线边框联接表虚线边框拥有类型浅色描边或内联字段技术表弱化style.opacity: 0.55迁移专属表点线边框级联删除在边上加cascade后缀标注。3. 分组与质量门禁按 references/grouping-modes.md 提供四种分组模式bounded-context按领域/文件夹聚类、schema按数据库 schema如public、auth、billing、namespace按 C# 命名空间、flat无容器适合小 schema。交付前对照 references/quality-gate.md 逐项自检确认所选DbContext、核对 Fluent API 与迁移中的表名、包含主外键与基数、按用户选择呈现联接表与拥有类型、隐藏的技术表必须在摘要中列出、用d2 fmt校验语法、容器内边使用完整点号路径并提供渲染命令。端到端流程小结将模型提取接入实际生成任务后完整链路为读取项目结构定位全部DbContext类与DbSetT声明。阅读OnModelCreating与所有IEntityTypeConfigurationT记录 Fluent API 配置。阅读实体类、拥有类型、枚举与值对象记录数据注解。存在迁移时读取迁移与模型快照核验表名、联接表、索引、删除行为与影子列。按「迁移 Fluent API 数据注解 约定 C# 形状」的优先级归并出规范化数据库模型。回答本技能规定的强制问卷选择DbContext、列显示范围、拥有类型与联接表的呈现方式、分组模式、布局引擎等快速生成时可采用 SKILL.md 中列出的默认值。生成.d2源文件用d2 fmt校验再用d2 --layoutelk schema.d2 schema.svg渲染输出。整个过程中模型提取efcore-model-extraction.md是第一步也是决定图质量的一步它把「读源码」变成了一套有顺序、有优先级、有核验手段的工程化流程保证最终生成的 D2 图反映的是 EF Core 的真实持久化模型而非 C# 类的表面形状。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/13 17:25:13 · 阅读 1.2k EF Core 模型提取实战指南：从 DbContext 与迁移到 D2 数据库关系图
EF Core 模型提取实战指南从 DbContext 与迁移到 D2 数据库关系图【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读本文讲解如何从任意 Entity Framework CoreEF Core代码库中系统化地提取数据库模型——包括表、列、主外键、索引、拥有类型与多对多联接表——并据此生成可渲染为 SVG/PNG 的 D2 实体关系图。文中方法源自本仓库efcore-d2-db-diagram技能中的模型提取规范见 references/efcore-model-extraction.md读完你既能掌握一套可复用的「源码检查 → 模型归并 → 图谱产出」流程也能准确判断 EF Core 各配置来源发生冲突时该以谁为准。为什么需要「模型提取」这一步EF Core 的持久化模型并不等于 C# 类的原始形状表名可能被ToTable改写外键可能是未在实体中声明的影子属性多对多关系可能由约定隐式生成联接表值对象可能通过OwnsOne/OwnsMany以独立表或内联列的形式持久化。因此直接照着实体类的字段画图几乎必然与实际数据库结构产生偏差。模型提取的目的正是建立一个「规范化后的数据库模型normalized database model」以数据库表为第一等公民明确每张表的真实名称、主键、外键、必填/可选列、索引、约束与删除行为之后再进入 D2 生成阶段。这也是 SKILL.md 中工作流第 7 步「Build a normalized database model before writing D2」所强调的关键中间产物。检查顺序从哪里开始读代码提取模型时应按下述顺序逐层检查源码。顺序本身是有意义的——越靠前的文件越能反映最终持久化形态DbContext类确定实体集与配置入口。通常一个DbContext对应一个数据库或一个限界上下文是整张图的根。DbSetT声明列出所有可被查询的实体集合是「哪些类型持久化为表」的第一线索。OnModelCreatingFluent API 的主战场集中定义表名、键、索引、关系与删除行为。IEntityTypeConfigurationT类按实体拆分的配置类常配合ApplyConfigurationsFromAssembly使用是 Fluent API 的结构化组织形式。实体类Entity classes确认属性、导航属性与数据注解。迁移与模型快照Migrations model snapshot验证最终落库的实际表结构。数据注解Data annotations[Key]、[Required]、[MaxLength]、[Column]、[Table]等特性标注的声明式约束。这一顺序与本仓库中 SKILL.md 推荐工作流的前 6 步一致先定位DbContext与DbSetT再读实体与配置类最后用迁移核验。映射优先级来源冲突时以谁为准不同配置来源可能相互矛盾——例如实体上用[Required]标注了必填但 Fluent API 里IsRequired(false)覆盖了它又例如迁移快照中的表名与实体类命名不一致。此时必须按下述优先级裁决而不是凭直觉最新迁移 / 模型快照这是数据库的「既成事实」代表已经应用或将要应用的真实结构优先级最高。Fluent APIOnModelCreating与IEntityTypeConfigurationT程序化配置优先级次之。数据注解声明式配置再次之。EF Core 约定Conventions在没有任何显式配置时才生效的默认行为。C# 类形状class shape仅作为兜底参考例如类型推断、属性命名映射。这条优先级在 SKILL.md 的「Source Priority」一节中被原样强调当来源不一致时始终以最新迁移/快照为准其次是 Fluent API再次是数据注解、约定最后才是 C# 原始形态。需要识别的关键 EF Core API提取时应在全库范围内检索下列 API它们各自对应数据库模型中的一类要素API提取的信息ToTable实际表名ToTable(Table, schema)还指定数据库 schemaHasKey主键多个属性构成复合主键HasAlternateKey备用键唯一约束HasIndex索引定义配合IsUnique得到唯一索引IsUnique索引唯一性标志Property对某个属性做精细映射列名、类型、长度、转换等的入口HasColumnName列的实际名称区别于属性名HasColumnType数据库列类型如varchar(200)IsRequired列/关系是否必填非空HasMaxLength字符串列最大长度HasConversion值转换器如枚举 ↔ 字符串、复杂对象 ↔ JSON影响持久化类型HasOne/WithMany/WithOne关系两端的导航配置HasForeignKey外键属性或影子外键列OnDelete删除行为Cascade/Restrict/NoAction/SetNull/ClientSetNullOwnsOne/OwnsMany拥有类型值对象可内联列或独立表UsingEntity显式声明多对多联接表Ignore被忽略的属性或实体不持久化图上不应出现识别出上述 API 后还需同步记录影子属性仅在 Fluent API 中配置、实体中不存在的属性、值转换对列类型的影响、枚举属性的持久化形式以及被Ignore排除的部分——后者在画图时必须主动剔除。用迁移校验事实快照里的真实结构迁移Migrations是模型提取的「事实核查层」因为它是 EF Core 根据模型计算出的、最终将应用到数据库的操作序列。通过迁移文件及其ModelSnapshot可以确认实际表名与ToTable配置或约定命名核对。联接表join tables多对多隐式生成的表实体类中往往不存在对应类型。影子外键列shadow FK columns未声明为实体属性、仅存在于数据库中的外键列。索引包括唯一索引与复合索引。复合键由多个列构成的主键或备用键。删除行为外键约束的ON DELETE语义。仅存在于迁移中的表migration-only tables例如__EFMigrationsHistory这类由 EF Core 自身维护、与业务实体无关的表。从迁移中读取这些信息后再回到实体与 Fluent API 对照验证——这正是「映射优先级」把迁移快照列为最高依据的原因。本仓库的 SKILL.md 也明确规定迁移数据用于「confirm table names, join tables, indexes and delete behaviors」并推荐在每次重新生成图之前都重新读取映射与迁移避免模型过期。提取结果如何进入 D2 图关系与分组规则模型提取的产出要落到.d2文件中需要配合本技能的其他参考文档完成三件事1. 关系推断参照 references/relationship-rules.md 将提取到的导航与键信息归并为四类关系统一用「从依赖表指向主表」的有向边表达一对多1:N由HasOne(...).WithMany(...)、依赖方外键属性、主方集合导航识别渲染为Orders.ClientId - Clients.Id: N:1。一对一1:1由HasOne(...).WithOne(...)、唯一外键索引或共享主键关系识别渲染为ClientProfiles.ClientId - Clients.Id: 1:1。多对多N:N由UsingEntity、双向集合导航无显式联接实体或迁移中带两个外键与复合键的联接表识别默认显式渲染联接表。拥有类型owned由OwnsOne、OwnsMany、[Owned]识别默认内联展示除非检测到表拆分或独立表映射。可选关系外键可空、配置了IsRequired(false)或迁移列为可空时判定为可选图中用虚线边表示。2. 表与样式表达参照 references/d2-erd-style.md 使用sql_table形状与统一样式类Clients: { shape: sql_table Id: uuid {constraint: primary_key} Name: varchar(200) Status: enum }样式约定定义于 SKILL.md 的 Style Rules主实体表实线边框联接表虚线边框拥有类型浅色描边或内联字段技术表弱化style.opacity: 0.55迁移专属表点线边框级联删除在边上加cascade后缀标注。3. 分组与质量门禁按 references/grouping-modes.md 提供四种分组模式bounded-context按领域/文件夹聚类、schema按数据库 schema如public、auth、billing、namespace按 C# 命名空间、flat无容器适合小 schema。交付前对照 references/quality-gate.md 逐项自检确认所选DbContext、核对 Fluent API 与迁移中的表名、包含主外键与基数、按用户选择呈现联接表与拥有类型、隐藏的技术表必须在摘要中列出、用d2 fmt校验语法、容器内边使用完整点号路径并提供渲染命令。端到端流程小结将模型提取接入实际生成任务后完整链路为读取项目结构定位全部DbContext类与DbSetT声明。阅读OnModelCreating与所有IEntityTypeConfigurationT记录 Fluent API 配置。阅读实体类、拥有类型、枚举与值对象记录数据注解。存在迁移时读取迁移与模型快照核验表名、联接表、索引、删除行为与影子列。按「迁移 Fluent API 数据注解 约定 C# 形状」的优先级归并出规范化数据库模型。回答本技能规定的强制问卷选择DbContext、列显示范围、拥有类型与联接表的呈现方式、分组模式、布局引擎等快速生成时可采用 SKILL.md 中列出的默认值。生成.d2源文件用d2 fmt校验再用d2 --layoutelk schema.d2 schema.svg渲染输出。整个过程中模型提取efcore-model-extraction.md是第一步也是决定图质量的一步它把「读源码」变成了一套有顺序、有优先级、有核验手段的工程化流程保证最终生成的 D2 图反映的是 EF Core 的真实持久化模型而非 C# 类的表面形状。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考