DbContext

A DbContext is your session with the database. You create one, do some reading and writing through it, save, and let it go.

It has two jobs worth naming before any code. It is a unit of work: it collects the changes you make and writes them in one transaction when you call SaveChanges. It is also an identity map: within one context, one row from the database is represented by exactly one object in memory, however many times you ask for it.

Those two jobs explain nearly every rule about DbContext, including the one people get wrong most often — how long it should live.

using Microsoft.EntityFrameworkCore;

public class AnviContext : DbContext
{
    public AnviContext(DbContextOptions<AnviContext> options)
        : base(options)
    {
    }

    public DbSet<Employee> Employees => Set<Employee>();
    public DbSet<Department> Departments => Set<Department>();
    public DbSet<Customer> Customers => Set<Customer>();
    public DbSet<Order> Orders => Set<Order>();
    public DbSet<OrderItem> OrderItems => Set<OrderItem>();
    public DbSet<Product> Products => Set<Product>();

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.ApplyConfigurationsFromAssembly(
            typeof(AnviContext).Assembly);
    }
}

• The constructor takes DbContextOptions rather than building its own connection. That is what lets the application decide the database and the settings, and what lets a test point the same context at something else.
• Each DbSet property is an entry point for queries against one entity type. A DbSet is not a collection of loaded objects — it is the starting point of an IQueryable, as the previous lesson described.
• Set<Employee>() is used instead of an auto-property so the properties can be read-only. Either form works; this one removes a settable property that nothing should ever set.
• OnModelCreating is where mapping rules go. ApplyConfigurationsFromAssembly picks up every configuration class in the project, which keeps this method from growing into a wall of rules. The next module covers what goes in those classes.

Employee first = await context.Employees.FindAsync(7);

// No SQL is sent this time. Employee 7 is already tracked.
Employee second = await context.Employees.FindAsync(7);

Console.WriteLine(ReferenceEquals(first, second)); // True

first.AnnualSalary = 62000m;
Console.WriteLine(second.AnnualSalary);            // 62000

await context.SaveChangesAsync();                  // one UPDATE

• FindAsync checks the change tracker before the database. The first call queries; the second finds employee 7 already tracked and returns the instance it has.
• ReferenceEquals is true because there is one object, not two copies. That is the identity map doing its job.
• The consequence is the line that surprises people: assigning through first changes what second reports, because they are the same object.
• SaveChangesAsync produces a single UPDATE containing only the changed column, because the tracker still holds the original salary to compare against.

builder.Services.AddDbContext<AnviContext>(options =>
    options.UseSqlServer(
        builder.Configuration.GetConnectionString("AnviDatabase")));

builder.Services.AddScoped<OrderService>();

// ---

public class OrderService
{
    private readonly AnviContext _context;

    public OrderService(AnviContext context) => _context = context;

    public async Task<List<Order>> GetRecentOrdersAsync(int customerId)
    {
        return await _context.Orders
            .Where(o => o.CustomerId == customerId)
            .OrderByDescending(o => o.PlacedOn)
            .Take(20)
            .ToListAsync();
    }
}

• AddDbContext registers the context with a scoped lifetime by default. In a web application a scope is created per request, so each request gets its own context and it is disposed when the response is finished.
• The connection string is read from configuration rather than written in code. Keep real connection strings out of source control — use user secrets in development and your platform's configuration store in production.
• OrderService asks for an AnviContext in its constructor and never creates one. It therefore takes whatever context belongs to the current request, without knowing that requests exist.
• Note that OrderService is registered as scoped too. A singleton service that depends on a scoped context would capture one context forever, which is the failure described below.