Why should you care?

ShopNest ProductService should depend on IProductRepository, not ShopNestDbContext directly — easier testing and clearer boundaries.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

public interface IProductRepository
{
    Task<Product?> GetBySkuAsync(string sku, CancellationToken ct);
    Task AddAsync(Product product, CancellationToken ct);
}

public class ProductRepository(ShopNestDbContext db) : IProductRepository
{
    public Task<Product?> GetBySkuAsync(string sku, CancellationToken ct) =>
        db.Products.FirstOrDefaultAsync(p => p.Sku == sku, ct);

    public Task AddAsync(Product product, CancellationToken ct) =>
        db.Products.AddAsync(product, ct).AsTask();
}

What happened?

• Repository delegates to DbContext internally.
• Service calls interface; SaveChangesAsync typically lives in unit of work or service after multiple repository ops.

Practice next

1. Extract product queries from service into ProductRepository.
2. Register IProductRepository as Scoped in DI.
3. Keep repositories focused — avoid generic IRepository for everything.
4. Add ListPublishedByCategoryAsync with encapsulated Include logic.
5. Fake repository returning fixed Product for service unit test.

Remember

Repository abstracts data access behind interfaces. Enables mocking in unit tests. Use when indirection pays for complexity.

ShopNest catalog service

ProductService unit tests mock IProductRepository for pricing rules without database.

Outcome: Fast CI tests for business logic separate from SQL integration.