17370845950

EF Core 支持多 DbContext，应按业务域划分、各司其职；分别注册、独立配置连接字符串与 OnModelCreating；跨库查询需应用层组合；迁移须显式指定上下文并隔离目录。

EF Core 支持一个应用中使用多个 DbContext，常见于微服务拆分、读写分离、多租户或不同业务模块隔离等场景。关键不是“能不能”，而是“怎么设计得清晰、不冲突、易维护”。

按业务域划分多个 DbContext

每个 DbContext 应聚焦单一职责，比如订单上下文只管订单、支付上下文只管支付，避免一个上下文映射几十张表。这样迁移、测试、升级都更可控。

• 为每个上下文定义独立的类，继承 DbContext
• 在 Startup.cs 或 Program.cs 中分别注册，指定不同连接字符串和生命周期（通常用 AddDbContext 多次调用）
• 每个上下文的 OnModelCreating 只配置自己负责的实体，不交叉

连接字符串与数据库隔离

多个上下文默认可指向不同数据库（甚至不同数据库类型），只要连接字符串和 Provider 配置正确。

• 在 appsettings.json 中配置多个连接字符串，如 OrderDbConnection、ProductDbConnection
• 注册时通过 options.UseSqlServer(...) 或 options.UseNpgsql(...) 指定对应连接字符串
• 注意：不同上下文之间不能直接跨库做 LINQ Join（除非数据库原生支持，如 SQL Server 的四部分名称），需应用层组合数据

依赖注入与使用方式

多个上下文注册后，可以直接通过构造函数注入，EF Core 会自动解析各自实例。

• 控制器或服务中同时接收 OrderDbContext 和 ProductDbContext 是完全合法的
• 确保它们的生命周期一致（推荐 Scoped），避免跨请求共享上下文实例
• 不要手动 new 上下文，也不要长期持有引用；用完即弃，由 DI 容器管理释放

迁移管理要分开操作

每个上下文的迁移文件彼此独立，命令行必须显式指定上下文类型。

• 添加迁移：dotnet ef migrations add Init -c OrderDbContext
• 更新数据库：dotnet ef database update -c ProductDbContext
• 迁移文件夹建议按上下文命名（如 Migrations/Orders、Migrations/Products），并用 --output-dir 参数控制生成路径

基本上就这些。多 DbContext 不复杂，但容易忽略职责边界和迁移隔离——理清“谁管什么、连哪里、怎么迁”，就能稳住架构底座。