DbContext & DbSet in EF Core

1. What is DbContext? The Zomato Analogy

DbContext = Waiter at restaurant.

1. You sit down = New request starts → New DbContext created.
2. You order = _db.Users.Add() → Waiter notes it. Doesn't run to kitchen yet.
3. You say "Done" = SaveChanges() → Waiter sends all orders to kitchen in 1 trip.
4. You leave = Request ends → Waiter forgets you. DbContext disposed.

Rule: 1 HTTP request = 1 DbContext. Never reuse across requests.

2. DbSet = Your Table

public class AppDbContext : DbContext
{
    public DbSet Users { get; set; } // Users table
    public DbSet Orders { get; set; } // Orders table
}

Query it: _db.Users.Where(u => u.IsActive) → EF translates to SQL.

3. Register It Right - Or Crash in Prod

Program.cs

builder.Services.AddDbContext(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

Default lifetime = Scoped. Perfect. New DbContext per request.

1. The Interview Theory: DbContext Lifetime

What is DbContext? Unit of Work + Repository pattern implementation. Tracks changes to entities. Batches SQL on SaveChanges().

Why Scoped? 1. Thread safety: DbContext is NOT thread-safe. 1 request = 1 thread. 2. ChangeTracker isolation: User A's changes don't leak to User B. 3. Connection pooling: Context opens/closes connection per operation. Short lifetime = connections return to pool fast.

2. The #1 Interview Question: "Why can't DbContext be Singleton?"

Your Answer: "3 reasons. 1. Not thread-safe. Singleton shared across requests = race conditions, data corruption. 2. ChangeTracker leak. It keeps all entities forever. 1000 requests = 1000x tracked data = OutOfMemoryException. 3. Stale data. Singleton caches entities. If another app updates DB, you never see it. Scoped = new context per request = fresh data, no leaks, thread-safe."

This answer gets you hired. "Because docs say so" gets you rejected.

3. 3 Ways to Configure DbContext

4. OnModelCreating - Fix EF's Defaults

EF Core defaults are lazy. Override them here.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    // 1. Fix nvarchar(max) perf killer
    modelBuilder.Entity()
       .Property(u => u.Name).HasMaxLength(100).IsRequired();

    // 2. Default SQL value
    modelBuilder.Entity()
       .Property(u => u.CreatedAt).HasDefaultValueSql("GETUTCDATE()");

    // 3. Index for fast search
    modelBuilder.Entity()
       .HasIndex(u => u.Email).IsUnique();
}

Staff Rule: If you don't set HasMaxLength, EF uses nvarchar(max). SQL can't index it. Your WHERE Name = 'X' does full table scan. 1M rows = 30s query.

5. DbSet vs Repository Pattern

Theory: DbSet<T> already IS a repository. DbContext already IS Unit of Work.

// JUNIOR: Wraps DbSet for no reason. Extra layer, extra bugs.
public class UserRepo {
    private readonly AppDb _db;
    public User Get(int id) => _db.Users.Find(id);
}

// SENIOR: Inject DbContext directly. Test with InMemory DB.
public class UserService {
    private readonly AppDbContext _db;
    public UserService(AppDbContext db) => _db = db;
}