Repository Pattern

A repository is an object that behaves like a collection of domain objects and hides where they are actually stored. You ask it for an invoice; it does not tell you whether that involved SQL, a cache or a web service.

The pattern predates modern object-relational mappers, and that history matters. It was written when data access meant hand-built SQL and manual mapping, so wrapping that work behind a collection-like interface was a substantial gain. Some of that gain is now provided by the ORM itself, which changes the calculation rather than settling it.

public interface IOrderRepository
{
    Task<Order?> GetByIdAsync(int id);
    Task<List<Order>> GetAllAsync();
    Task AddAsync(Order order);
    Task SaveChangesAsync();
}

public sealed class OrderRepository(OrdersDbContext db) : IOrderRepository
{
    public Task<Order?> GetByIdAsync(int id) => db.Orders.FindAsync(id).AsTask();

    public Task<List<Order>> GetAllAsync() => db.Orders.ToListAsync();

    public Task AddAsync(Order order)
    {
        db.Orders.Add(order);
        return Task.CompletedTask;
    }

    public Task SaveChangesAsync() => db.SaveChangesAsync();
}

• Every method forwards one call. DbSet already offers FindAsync, ToListAsync and Add, and DbContext.SaveChangesAsync already commits one transaction, so nothing here is new capability.
• What it did add: an interface, an implementation, a registration line, and a fake for every test that touches orders. Four things to maintain in exchange for the same behaviour.
• GetAllAsync is worse than what it replaced. Through the DbSet a caller could filter, sort and page in the database. Through this method the whole table comes back and filtering happens in memory — on a table with a million orders that is a production incident waiting for a slow week.
• AddAsync is not asynchronous. Returning Task.CompletedTask to fit the interface is a sign the abstraction was shaped by habit rather than by what the caller needs.

With EF Core there is a specific reason this happens. DbContext is already a unit of work: it tracks the changes you make and commits them together when you call SaveChangesAsync. DbSet is already a queryable abstraction over a collection of entities. A repository that only forwards to them is duplicating an abstraction you already have.

That is not an argument against repositories. It is an argument against repositories with no job. A repository earns its place when it does something the DbSet does not — and there are three things worth doing.

public interface IInvoiceRepository
{
    Task<Invoice?> FindAsync(int id, CancellationToken token);
    Task<IReadOnlyList<Invoice>> UnpaidForCustomerAsync(int customerId, CancellationToken token);
    void Add(Invoice invoice);
}

internal sealed class EfInvoiceRepository(InvoicingDbContext db, ITenantContext tenant)
    : IInvoiceRepository
{
    // Every query starts here, so neither filter can be forgotten.
    private IQueryable<Invoice> Visible =>
        db.Invoices.Where(invoice => invoice.TenantId == tenant.Id && !invoice.IsArchived);

    public async Task<Invoice?> FindAsync(int id, CancellationToken token) =>
        await Visible
            .Include(invoice => invoice.Lines)
            .FirstOrDefaultAsync(invoice => invoice.Id == id, token);

    public async Task<IReadOnlyList<Invoice>> UnpaidForCustomerAsync(
        int customerId, CancellationToken token) =>
        await Visible
            .Where(invoice => invoice.CustomerId == customerId && invoice.Status != InvoiceStatus.Paid)
            .OrderBy(invoice => invoice.DueUtc)
            .ToListAsync(token);

    public void Add(Invoice invoice) => db.Invoices.Add(invoice);
}

• The tenant filter and the archive filter are applied in one place. A developer adding a query next year cannot forget them, because there is no route to the table that skips them. Getting that wrong means showing one customer another customer's invoices, so a single enforced location is worth real money.
• Method names state intent — unpaid invoices for a customer — rather than exposing a query language. A reader of the calling code learns what is being asked for, not how.
• Results come back as IReadOnlyList, and only loaded invoices come with their lines. Callers cannot accidentally leave a query open and trigger further database work later.
• There is no SaveChangesAsync here. The use case owns the transaction boundary, so it calls SaveChangesAsync once after all the work, and two repository operations commit together.
• Worth knowing: EF Core can apply the tenant and archive filters itself through a global query filter configured on the model. If that is all you need, the filter is a few lines in your context configuration and no repository is required.