Using DbContext in ASP.NET MVC

For a comprehensive overview of DbContext and its core features, please see our Entity Framework DbContext documentation.

This guide focuses on DbContext patterns and best practices specific to ASP.NET MVC applications.

Introduction
Why Do We Need DbContext?
Common DbContext Patterns
- Single DbContext per Request
- Repository Pattern with DbContext
Why Create a Separate DbContext File?
Best Practices
Common Pitfalls to Avoid
Next Steps

Introduction

DbContext is a crucial part of Entity Framework that acts as a bridge between your application and the database. Think of it as your database session - it’s responsible for tracking changes, managing relationships, and handling database operations.

Why Do We Need DbContext?

1. Database Connection Management

public class ShopContext : DbContext
{
    // DbContext handles opening and closing database connections
    public ShopContext(DbContextOptions<ShopContext> options)
        : base(options)
    {
    }
}

Automatically manages database connections
Handles connection pooling for better performance
Ensures connections are properly closed after use

2. Change Tracking

using (var context = new ShopContext())
{
    var product = context.Products.Find(1);
    product.Price = 29.99m;
    // DbContext tracks that this product was modified
    context.SaveChanges(); // Only updates what changed
}

Tracks which entities have been modified
Only saves actual changes to the database
Prevents unnecessary database updates

3. Query Management

public class ShopContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    public DbSet<Category> Categories { get; set; }

    // DbContext lets you query related data easily
    public async Task<List<Product>> GetProductsWithCategories()
    {
        return await Products
            .Include(p => p.Category)
            .ToListAsync();
    }
}

Provides LINQ support for database queries
Handles SQL generation
Manages query execution and caching

4. Relationship Management

public class ShopContext : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // DbContext manages relationships between entities
        modelBuilder.Entity<Product>()
            .HasOne(p => p.Category)
            .WithMany(c => c.Products)
            .HasForeignKey(p => p.CategoryId);
    }
}

Handles foreign key relationships
Manages navigation properties
Ensures data consistency

5. Transaction Management

using (var context = new ShopContext())
{
    using (var transaction = context.Database.BeginTransaction())
    {
        try
        {
            // Multiple operations in one transaction
            context.Products.Add(newProduct);
            context.Categories.Remove(oldCategory);
            context.SaveChanges();
            transaction.Commit();
        }
        catch
        {
            transaction.Rollback();
        }
    }
}

Ensures data consistency
Handles transaction rollback on errors
Supports nested transactions

Common DbContext Patterns

1. Single DbContext per Request

public class ProductsController : Controller
{
    private readonly ShopContext _context;

    // Inject one DbContext for the entire request
    public ProductsController(ShopContext context)
    {
        _context = context;
    }
}

2. Repository Pattern with DbContext

public class ProductRepository : IProductRepository
{
    private readonly ShopContext _context;

    public ProductRepository(ShopContext context)
    {
        _context = context;
    }

    public async Task<Product> GetById(int id)
    {
        return await _context.Products.FindAsync(id);
    }
}

Best Practices

1. Proper Disposal and Resource Management

Why Disposal Matters

DbContext holds important resources:

Database connections
Memory for tracking entities
Cached query results

Not disposing properly can lead to:

Memory leaks
Connection pool exhaustion
Slow application performance

Bad Practice ❌

public class ProductController : Controller
{
    // DON'T: Creating DbContext without proper disposal
    private ShopContext _context = new ShopContext();

    public IActionResult Index()
    {
        // Context might stay open too long
        return View(_context.Products.ToList());
    }
    // Context never gets disposed!
}

Good Practice ✅

// GOOD: Let dependency injection handle lifecycle
public class ProductController : Controller
{
    private readonly ShopContext _context;

    public ProductController(ShopContext context)
    {
        _context = context;
    }
}

// Register for proper disposal
public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ShopContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")),
        ServiceLifetime.Scoped); // One instance per request
}

When Manual Disposal is Needed

// Use 'using' for manual context creation
public async Task ImportData(string fileName)
{
    using (var context = new ShopContext())
    {
        // Context gets disposed even if an exception occurs
        await ProcessFile(context, fileName);
    } // Automatic disposal here
}

// Or using C# 8.0+ syntax
public async Task ExportData()
{
    await using var context = new ShopContext();
    // Process data...
} // Automatic disposal here

2. Connection Management

public class ShopContext : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        // GOOD: Enable connection resiliency
        optionsBuilder.UseSqlServer(connectionString, options => 
        {
            options.EnableRetryOnFailure(
                maxRetryCount: 3,
                maxRetryDelay: TimeSpan.FromSeconds(5),
                errorNumbersToAdd: null);
        });
    }
}

3. Performance Optimization

// GOOD: Use async methods for better scalability
public class ProductController : Controller
{
    private readonly ShopContext _context;

    public async Task<IActionResult> Index()
    {
        // Async operation doesn't block threads
        return View(await _context.Products
            .AsNoTracking() // Don't track if not needed
            .ToListAsync());
    }

    public async Task<IActionResult> Search(string term)
    {
        // GOOD: Efficient querying
        return View(await _context.Products
            .Where(p => p.Name.Contains(term))
            .Select(p => new ProductViewModel // Select only what you need
            {
                Id = p.Id,
                Name = p.Name
            })
            .ToListAsync());
    }
}

4. Change Tracking Management

// Configure tracking behavior globally
services.AddDbContext<ShopContext>(options =>
{
    options.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
});

// Or per-query
public async Task<List<Product>> GetProducts()
{
    // Don't track entities for read-only operations
    return await _context.Products
        .AsNoTracking()
        .ToListAsync();
}

// Enable tracking only when needed
public async Task UpdateProduct(int id)
{
    var product = await _context.Products
        .FindAsync(id); // Tracking enabled for updates
    
    product.LastUpdated = DateTime.UtcNow;
    await _context.SaveChangesAsync();
}

2. Configuration in Startup

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ShopContext>(options =>
    {
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"));
        options.EnableSensitiveDataLogging(isDevelopment);
        options.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
    });
}

3. Context Separation

// Separate contexts for different bounded contexts
public class OrderContext : DbContext { }
public class InventoryContext : DbContext { }

Common Pitfalls to Avoid

Long-Living DbContext
- Don’t keep DbContext alive for multiple requests
- Use dependency injection for proper lifecycle management
Missing Dispose
- Always dispose DbContext when manually creating
- Use using statements or dependency injection
Heavy DbContext
- Don’t put business logic in DbContext
- Keep it focused on data access
Sharing DbContext
- Don’t share DbContext between threads
- Each thread should have its own instance

Why Create a Separate DbContext File?

1. Separation of Concerns

// Data/ShopContext.cs - Handles database configuration
public class ShopContext : DbContext
{
    public DbSet<Product> Products { get; set; }
    public DbSet<Category> Categories { get; set; }
}

// Controllers/ProductController.cs - Handles HTTP requests
public class ProductController : Controller
{
    private readonly ShopContext _context;
    // Controller focuses on handling requests, not database setup
}

// Models/Product.cs - Defines data structure
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Each file has a single responsibility
Makes code easier to maintain and test
Follows SOLID principles

2. Reusability

// Can be used by multiple controllers
public class ProductController : Controller
{
    private readonly ShopContext _context;
}

public class OrderController : Controller
{
    private readonly ShopContext _context;
}

public class InventoryController : Controller
{
    private readonly ShopContext _context;
}

Same DbContext can be used across different parts of the application
Prevents duplicate database configuration code
Ensures consistent database access patterns

3. Configuration Management

public class ShopContext : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // All database configuration in one place
        modelBuilder.Entity<Product>()
            .HasIndex(p => p.Name);
        
        modelBuilder.Entity<Category>()
            .HasMany(c => c.Products)
            .WithOne(p => p.Category)
            .OnDelete(DeleteBehavior.Cascade);
            
        modelBuilder.Entity<Product>()
            .Property(p => p.Price)
            .HasPrecision(18, 2);
    }
}

Centralizes all database configuration
Makes it easier to manage database changes
Keeps configuration separate from business logic

4. Testing

// Easy to mock for testing controllers
public class ProductControllerTests
{
    [Fact]
    public async Task GetProduct_ReturnsProduct()
    {
        // Can create test double of DbContext
        var mockContext = new Mock<ShopContext>();
        var controller = new ProductController(mockContext.Object);
        
        var result = await controller.GetProduct(1);
        Assert.IsType<Product>(result);
    }
}

Easier to create mock database contexts
Can test controllers without real database
Supports unit testing and integration testing

5. Dependency Injection

public void ConfigureServices(IServiceCollection services)
{
    // Register DbContext once, use everywhere
    services.AddDbContext<ShopContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
}

Single place to configure database connection
Easy to switch database providers
Proper lifecycle management

6. Code Organization

YourApp/
├── Controllers/
│   ├── ProductController.cs
│   └── CategoryController.cs
├── Models/
│   ├── Product.cs
│   └── Category.cs
└── Data/
    └── ShopContext.cs  // All database config in one place

Clear project structure
Easy to find database-related code
Better team collaboration

Next Steps

Learn about Entity Framework Core migrations
Explore advanced querying techniques
Study performance optimization strategies