将大型数据库拆分为多个DbContext的EF Core技术问题咨询

可以通过关联不完整的DbContext采用Code-First模式管理整个数据库，但需要结合特定配置策略规避跨上下文关联的限制。以下是几种可行的落地方案：

方案一：拆分DbContext + 外键字段替代导航属性 #

• 每个业务领域的DbContext仅包含自身领域的实体，跨领域关联仅保留外键字段（不定义导航属性）。例如Order实体只保留CustomerId，不添加Customer导航属性。
• 抽离共享实体类库，所有DbContext引用该库，确保同一实体的结构定义完全一致。
• 迁移时，每个DbContext的迁移脚本仅处理自身领域的表结构；跨领域的外键约束需手动编写迁移代码添加（默认拆分DbContext不会自动生成跨上下文的约束）。
• 查询跨领域数据时，需手动通过外键关联查询，例如先从OrderDbContext获取CustomerId，再到CustomerDbContext查询对应的客户信息。

方案二：垂直拆分DbContext（官方推荐架构划分） #

• 利用EF Core的ModelBuilder.Entity<T>().ToTable("TableName", "SchemaName")方法，将不同领域的表映射到独立架构下，每个DbContext负责一个架构的表。
• 跨领域关联可保留导航属性，但仅在其中一个DbContext中配置完整关联（包含导航属性和外键），另一个DbContext仅保留外键字段。例如在OrderDbContext中配置Order到Customer的导航属性，CustomerDbContext中不定义反向导航。
• 迁移管理：创建一个主DbContext（或指定某个核心领域的DbContext）负责全库迁移，或通过dotnet ef migrations add -c [DbContextName]分别生成各领域迁移，再手动合并迁移脚本（需保证依赖表的创建顺序）。
• 优势：每个DbContext仅加载自身领域的模型，初始化速度大幅提升，同时完全通过Code-First管控整个数据库结构。

方案三：Code-First为主 + 反向工程辅助的混合模式 #

• 先通过Code-First定义各领域的实体和DbContext，生成初始数据库结构。
• 后续若有跨领域的结构调整，使用dotnet ef dbcontext scaffold命令反向生成实体类，将生成的代码合并到现有Code-First项目中，手动调整导航属性和DbContext划分，保持数据库结构在代码库内管理。
• 注意：反向生成后需同步更新共享实体类库，避免结构不一致。

关键注意事项 #

• 跨DbContext事务：EF Core 5及以上版本支持TransactionScope处理跨上下文事务（需数据库支持分布式事务），或手动开启数据库事务并共享连接。
• 迁移顺序：必须确保被依赖的表（如Customer）先于依赖表（如Order）创建，避免迁移失败。
• 实体唯一性：禁止在多个DbContext中重复配置同一实体，否则会导致模型冲突。

内容的提问来源于stack exchange，提问作者this.harry