按用例创建独立DbContext还是使用单一DbContext？

你的思路完全合理，按业务用例拆分DbContext是处理大型数据库场景的有效方案，你提到的两个核心优势——隐藏无关数据、降低上下文初始化开销，正是这种设计的核心价值所在。

为什么这种思路可行？ #

• 职责边界清晰：每个DbContext只聚焦特定业务场景，比如专门的AuthDbContext处理登录密码验证，PermissionDbContext管理用户权限，BusinessModuleDbContext处理whatever系列表的CRUD。开发时能明确每个上下文的作用，避免无关操作混入。
• 性能优化明确：EF Core初始化DbContext时会加载所有关联实体的元数据，拆分后每个上下文只需加载对应业务的实体元数据，确实能减少初始化阶段的资源消耗，尤其在频繁创建上下文的场景下效果更明显。
• 安全隔离有效：权限相关的上下文不会包含业务表实体，避免了误操作或权限溢出导致的业务数据风险。

实现的最佳实践 #

1. 按业务领域/模块拆分，而非细粒度操作拆分
   不要为每个单一操作（比如“验证密码”单独建上下文），而是按业务模块分组。例如：

   • 身份认证模块：包含User、ApplicationRight、UserApplicationRight表的上下文
   • 业务模块：按业务逻辑把whatever1、whatever2等归到对应领域的上下文（如订单、库存等）

2. 抽离共享基础上下文
   多个上下文如果需要相同的数据库连接、日志、拦截器等配置，可以创建抽象基础上下文，避免重复代码：

   public abstract class BaseAppDbContext : DbContext
   {
       protected BaseAppDbContext(DbContextOptions options) : base(options) { }
   
       // 共享配置，比如全局模型过滤、审计拦截器等
       protected override void OnModelCreating(ModelBuilder modelBuilder)
       {
           // 全局配置逻辑
       }
   }
   
   public class AuthDbContext : BaseAppDbContext
   {
       public DbSet<User> Users { get; set; }
       public DbSet<ApplicationRight> ApplicationRights { get; set; }
       public DbSet<UserApplicationRight> UserApplicationRights { get; set; }
   
       public AuthDbContext(DbContextOptions<AuthDbContext> options) : base(options) { }
   }
   

3. 避免跨上下文的实体关联
   EF Core无法处理不同DbContext之间的导航属性关联，因为每个上下文对应独立的模型集合。如果业务需要跨上下文数据交互，优先在业务层通过ID手动关联，而非强行建立EF导航属性。如果关联需求频繁，说明对应的上下文应该合并。

4. 针对只读场景优化
   如果某个上下文仅用于查询操作（比如登录验证只读取用户密码），可以关闭变更追踪提升性能：

   protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
   {
       optionsBuilder.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
   }
   

5. 管理好迁移流程
   每个DbContext会生成独立的迁移文件，执行迁移时需指定目标上下文：

   # 添加迁移
   Add-Migration AuthInitial -Context AuthDbContext
   # 更新数据库
   Update-Database -Context AuthDbContext
   

   若多个上下文操作同一数据库，需注意迁移顺序，避免出现表依赖导致的创建失败问题。

内容的提问来源于stack exchange，提问作者Gregor Fey