EF Core与.NET Core 3.0中DbContext及DbSet使用的最佳实践咨询

Hey Paul, great question—this is a super common decision point when scaling up EF Core projects, and the answer really depends on how your application is structured and where you see it going. Let’s break down the best practices for both approaches:

Single DbContext with All DbSets #

This is the default and most straightforward approach, and it’s totally valid for your scenario (10 DbSets, single database) if:

• Your application has a unified business domain (no clear, isolated modules)
• Most of your entities are interrelated, and cross-table queries are frequent
• You’re working on a small-to-medium sized app where simplicity is key

Pros: #

• Less boilerplate: No need to duplicate configuration (like connection strings, model building logic) across multiple contexts
• Easier relationship management: EF Core handles entity relationships seamlessly when all entities are in one context
• Simpler CRUD workflows: A single entry point for all database operations reduces cognitive load for your team

Tips to keep it maintainable: #

• Use partial classes to split your DbContext into logical chunks (e.g., UserDbContextPart.cs for user-related DbSets, OrderDbContextPart.cs for order entities) instead of cramming everything into one huge file
• Leverage Include()/ThenInclude() for explicit eager loading to avoid accidental lazy loading overhead
• Use AsNoTracking() for read-heavy queries to boost performance

Multiple DbContexts (Per Module/Domain) #

You’ll want to consider splitting into multiple DbContexts if:

• Your application is structured around distinct business modules (e.g., Users, Orders, Inventory) with minimal cross-module entity dependencies
• You’re following Domain-Driven Design (DDD) principles and want to enforce clear boundaries between domains
• Your team is large, and splitting contexts reduces merge conflicts and makes individual modules easier to test

Pros: #

• Single Responsibility Principle: Each context only cares about a specific set of entities, making code easier to reason about and maintain
• Better testability: You can write unit/integration tests for a single module without loading the entire data model
• Scalability: As your app grows, adding new modules with their own contexts keeps your codebase organized

Caveats to watch for: #

• Cross-module queries become trickier—if you need to join entities from two contexts, you’ll either need to use database views/stored procedures, or create a temporary "query-only" DbContext that includes both sets (use this sparingly to avoid breaking domain boundaries)
• You’ll need to duplicate some configuration (like connection strings) across contexts, though you can centralize this using .NET Core’s configuration system

Final Recommendation #

For your current setup (10 DbSets, single database), start with a single DbContext—it’s simpler and won’t cause performance issues (EF Core’s change tracker only tracks entities you’ve loaded, so having extra DbSets doesn’t bloat memory or slow down queries). If you later find that your app is splitting into distinct, isolated modules, you can refactor to multiple contexts gradually.

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