Implementing dependency injection with generic repositories in EF Core

Australian engineering teams that build on ASP.NET Core frequently reach for two patterns that travel well together: the generic repository and the built-in inversion of control container. When paired with Entity Framework Core, they decouple data access from controllers, Razor Pages, and background workers, and they make unit testing practical without reaching for brittle database fixtures. Conference attendees in Sydney and Melbourne often raise the same question: how do you wire these pieces together so that DbContext lifetimes stay correct and the architecture still holds up six months later.

The .NET ecosystem around EF Core has stabilised, and the tooling available in Visual Studio 2022 and JetBrains Rider on Australian workstations has matured to the point where the conversation has moved from "can we make it work" to "can we make it clean". Azure regions in Australia East (Sydney) and Australia Southeast (Victoria) keep SQL traffic close to the application tier, removing the latency that used to make teams hesitate before splitting services into multiple scopes.

This walkthrough covers a generic repository interface, a concrete implementation, the service registrations that respect EF Core's scoped lifetime, and the asynchronous patterns that suit Australian workloads. Along the way it touches on how the Australian Privacy Principles under the Privacy Act 1988 shape what repository methods should and should not return to callers.

Comparing DI lifetimes against EF Core requirements

Before any code is written, it is worth pausing on the lifetimes exposed by IServiceCollection. EF Core's DbContext is intentionally scoped, and any repository that wraps it must follow the same rule.

A singleton repository holding a scoped DbContext throws at startup. A transient repository holding a scoped context throws at runtime once the framework disposes the context mid-operation. The default Microsoft recommendation, and the one used in the rest of this article, is Scoped for any class that owns a DbContext.

Designing the generic repository interface

A repository interface should read like a contract, not a one-off facade. The shape below keeps the surface async, accepts cancellation tokens, and leaves room for entity-specific extensions through a second generic parameter.

public interface IRepository<TEntity, TKey> where TEntity : class
{
    Task<TEntity?> GetByIdAsync(TKey id, CancellationToken cancellationToken = default);
    Task<IReadOnlyList<TEntity>> ListAsync(
        Expression<Func<TEntity, bool>>? predicate = null,
        CancellationToken cancellationToken = default);
    Task AddAsync(TEntity entity, CancellationToken cancellationToken = default);
    void Update(TEntity entity);
    void Remove(TEntity entity);
    Task<int> SaveChangesAsync(CancellationToken cancellationToken = default);
}

Each method accepts a CancellationToken with a default value, which means ASP.NET Core controllers can simply pass the request token through. Background services hosted in IHostedService implementations can supply their own token and react to graceful shutdown signals coming from Kubernetes or Azure Container Apps. Restricting TEntity to a reference type avoids the corner case of value-type entities that EF Core would still try to track.

The optional predicate parameter on ListAsync lets callers express simple filters directly, while complex queries still belong in dedicated query handlers or specifications. Keeping the interface narrow makes mocking trivial in unit tests with NSubstitute or Moq, which matters for teams working under APRA CPS 234 where test coverage of data access paths is part of the evidence pack.

Building the concrete implementation

The concrete class is a thin wrapper around DbContext, and intentionally so. Wrapping too much logic hides the unit of work behaviour that DbContext already provides and tempts developers to add caching layers where EF Core's change tracker would do the same job.

public class Repository<TEntity, TKey> : IRepository<TEntity, TKey>
    where TEntity : class
{
    private readonly DbContext _db;
    private readonly DbSet<TEntity> _set;

    public Repository(DbContext db)
    {
        _db = db;
        _set = db.Set<TEntity>();
    }

    public Task<TEntity?> GetByIdAsync(TKey id, CancellationToken ct = default)
        => _set.FindAsync(new object[] { id! }, ct).AsTask();

    public async Task<IReadOnlyList<TEntity>> ListAsync(
        Expression<Func<TEntity, bool>>? predicate = null, CancellationToken ct = default)
    {
        var query = _set.AsNoTracking().AsQueryable();
        if (predicate is not null) query = query.Where(predicate);
        return await query.ToListAsync(ct);
    }

    public async Task AddAsync(TEntity entity, CancellationToken ct = default)
        => await _set.AddAsync(entity, ct);

    public void Update(TEntity entity) => _set.Update(entity);
    public void Remove(TEntity entity) => _set.Remove(entity);
    public Task<int> SaveChangesAsync(CancellationToken ct = default) => _db.SaveChangesAsync(ct);
}

AsNoTracking() on read paths is a deliberate choice for query endpoints. Tracking adds memory pressure and slows down read-heavy workloads like the dashboards seen in Australian fintech and health platforms. Tracking should be opt-in, not the default. For endpoints that need to update the same entity they read, the caller can use IQueryable projections or simply call Update afterwards, which EF Core handles correctly when the entity was loaded with identity resolution.

Registering services in the ASP.NET Core container

Registration belongs in Program.cs (or Startup.cs for older projects). A small extension method keeps the surface tidy and lets feature modules register their own repositories later.

public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddGenericRepositories(this IServiceCollection services)
    {
        services.AddScoped(typeof(IRepository<,>), typeof(Repository<,>));
        return services;
    }
}

The call site stays simple, and it sits in Program.cs next to the DbContext registration:

builder.Services.AddDbContext<AppDbContext>(opts =>
    opts.UseSqlServer(builder.Configuration.GetConnectionString("AppDb")));

builder.Services.AddGenericRepositories();
builder.Services.AddScoped<IOrderService, OrderService>();

The order of calls only affects readability, not resolution. As long as DbContext is registered before IRepository<,>, the container walks the graph correctly. Teams running distributed systems across Australia East and Australia Southeast should keep connection strings close to the application tier to avoid the cross-region data egress fees that surface under Microsoft's pricing model. Async correctness shows up the moment the repository is consumed. A common mistake is awaiting inside Parallel.ForEachAsync without a shared CancellationToken, which leads to half-completed batches when a worker shuts down at 09:00 AEST on a Monday morning.

public async Task ProcessAsync(IEnumerable<int> ids, CancellationToken ct)
{
    await Parallel.ForEachAsync(ids, new ParallelOptions
    {
        MaxDegreeOfParallelism = 4,
        CancellationToken = ct
    }, async (id, token) =>
    {
        var order = await _repo.GetByIdAsync(id, token);
        // process order
    });
}

For unit tests, the abstraction allows mocking with NSubstitute or Moq. Integration tests can swap the in-memory provider for Testcontainers running SQL Server, which mirrors the production runtime closely enough to catch provider-specific behaviour. Teams in regulated industries often pair these tests with synthetic data generators so that no real customer information ever enters a development environment, an approach that lines up with the spirit of the Notifiable Data Breaches scheme.

Compliance, auditing, and local realities

Several pieces of Australian legislation shape how repository methods are designed in practice. The Australian Privacy Principles require that personal information be collected only by fair means and that access be limited to those who need it. That principle encourages repository methods that accept authorisation filters as parameters rather than fetching whole entity graphs by default and trimming later in the controller.

APRA CPS 234 adds another layer for banks, insurers, and superannuation funds, demanding demonstrable controls around information assets and resilience to information security incidents. In code, that often translates into audit fields on every entity, repository hooks that stamp LastModifiedBy and LastModifiedUtc, and a logging pipeline that records every cross-region read against Australian-hosted SQL.

Practical habits in local teams reflect these rules. Engineers in Brisbane and Perth often add AsSplitQuery() for queries that span many optional includes, reducing the chance of cartesian explosion when audit log tables grow into the hundreds of millions of rows. Many shops enable EF Core's EnableSensitiveDataLogging only in development, behind an environment check, so connection strings and parameter values never leak into production log streams hosted in Australian regions. The ACSC Essential Eight maturity targets push teams towards explicit database roles, separate connection strings for migrations, and a DbContext factory that background workers use to escape the scoped lifetime without leaking it into the host.

The combination of generic repositories, scoped DbContext registration, and a thoughtful async surface keeps the architecture clean. It also lines up with the conventions taught at community events across the country, from the .NET user groups in Sydney and Melbourne to the sessions at the C# Corner Annual Conference 2020, where the focus stays firmly on shipping production code rather than debating abstract patterns.