DbContext vs Repository/Unit-of-Work Abstractions: Avoid Redundant Layers and Preserve Testable Boundaries

Learning outcomes

1. The architecture problem: abstraction can either clarify ownership or hide the database

ServiceHub has reached production scale. The team proposes an IRepository<T> with methods mirroring Add, Find, Update, Remove and Save because “repositories are cleaner.” That can be useful only if the abstraction owns a meaningful boundary. If it merely renames EF methods, it adds code while hiding query shape, tracking, transactions, provider features and generated SQL.

A unit of work coordinates a set of changes and commits them together. EF’s DbContext already tracks entity changes and SaveChanges persists them as one unit; a DbSet<T> already offers repository-like access to an entity set. A repository should therefore represent a domain capability or policy, not an EF-shaped forwarding layer.

2. Direct DbContext keeps the real mechanism visible

public sealed class ReviseWorkOrderHandler(ServiceHubContext db){    public async Task HandleAsync(int id, string summary, CancellationToken ct)    {        var order = await db.WorkOrders.SingleAsync(w => w.Id == id, ct);        order.ReviseSummary(summary);       // aggregate validates + advances Revision        await db.SaveChangesAsync(ct);      // one EF unit of work    }}

UPDATE "work_orders"SET "summary" = @p0, "revision" = @p1WHERE "work_order_id" = @p2  AND "revision" = @p3RETURNING 1;

The handler is not “coupled to SQL” merely because it knows EF. It is deliberately coupled to a persistence technology at the application/infrastructure boundary, while the aggregate method owns the business invariant. Generated SQL, the Revision predicate and tenant filters remain inspectable.

3. A useful repository speaks domain language and owns loading policy

public interface IWorkOrderRepository{    Task<WorkOrder?> LoadForRevisionAsync(int id, CancellationToken ct);    void Add(WorkOrder order);}public sealed class EfWorkOrderRepository(ServiceHubContext db)    : IWorkOrderRepository{    public Task<WorkOrder?> LoadForRevisionAsync(int id, CancellationToken ct)        => db.WorkOrders            .Include(w => w.Notes)            .SingleOrDefaultAsync(w => w.Id == id, ct);    public void Add(WorkOrder order) => db.WorkOrders.Add(order);}

This repository earns its existence if “load for revision” is a stable aggregate policy. Notice that it does not expose SaveAsync: the application transaction owner controls SaveChanges across all participating aggregates/outbox rows.

4. Deliberate failure: mechanical generic repository

public interface IRepository<T> where T : class{    IQueryable<T> Query();    Task<T?> FindAsync(object id);    void Add(T item);    void Update(T item);    void Remove(T item);    Task SaveAsync();}

This interface leaks IQueryable while simultaneously hiding EF’s transaction owner. Callers can compose unbounded includes, disable filters, change tracking behavior, or call SaveAsync halfway through a larger operation. It also makes provider-specific features awkward and tends to recreate EF’s API poorly.

5. IQueryable is a boundary decision, not a free abstraction

Returning IQueryable<WorkOrder> hands the caller the power to change translation, cardinality, tracking and often security-sensitive shape. That can be appropriate inside a trusted application layer; it is usually inappropriate across module/API boundaries.

6. Testing the seam: fake business decisions, not database translation

public sealed class EscalationPolicy{    public bool RequiresSupervisor(int priority, bool isAfterHours)        => priority >= 4 || (priority >= 3 && isAfterHours);}[Fact]public void Priority_four_requires_supervisor()    => Assert.True(new EscalationPolicy().RequiresSupervisor(4, false));

await using var db = factory.CreateForTenant("tenant-a");var query = db.WorkOrders.Where(w => w.Priority >= 3).Take(20);var sql = query.ToQueryString();Assert.Contains("tenant_id", sql, StringComparison.OrdinalIgnoreCase);var rows = await query.ToListAsync();

The unit test needs no EF mock. The integration test verifies translation, tenant filter, constraints and provider behavior against SQLite or the production-like provider from Chapter 23.

7. Mandatory lab: delete the redundant layer, then justify one useful boundary

1. Implement one ServiceHub command directly with ServiceHubContext and capture ChangeTracker.DebugView plus generated SQL.
2. Wrap the same operation in a generic repository that mirrors EF; list which EF capabilities became hidden or duplicated.
3. Replace it with either a domain-specific aggregate repository or bounded query service.
4. Verify that tenant filters and Revision concurrency still appear in SQL.
5. Write one pure business-policy unit test and one relational integration test.
6. Document who owns SaveChanges and the transaction boundary.

8. Production judgment and bridge

There is no universal “EF must always/never be behind a repository” rule. Choose the boundary that makes invariants, transaction ownership, query shape and provider behavior reviewable. The next lesson uses that discipline to model the WorkOrder aggregate, complex values, domain events and the existing outbox without turning persistence hooks into a message broker.

Authoritative references

• DbContext lifetime/configuration — DbContext as a short-lived unit of work and thread-safety/lifetime rules
• EF Core testing strategy — why translation and relational behavior require real provider testing
• Efficient querying — query-shape and projection/cardinality guidance
• Global query filters — tenant/filter behavior that abstractions must not accidentally bypass
• Advanced performance topics — context pooling and EF/runtime overhead boundaries
• Transactions in EF Core — SaveChanges and explicit transaction ownership