Why should you care?

ShopNest Application layer should not know about Include chains — repository methods express domain language like GetOpenOrdersForCustomer.

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 IOrderRepository
{
    Task<Order?> GetWithItemsAsync(int orderId, CancellationToken ct);
    Task<IReadOnlyList<Order>> ListRecentForCustomerAsync(int customerId, int take, CancellationToken ct);
}

public class OrderRepository(ShopNestDbContext db) : IOrderRepository
{
    public Task<Order?> GetWithItemsAsync(int orderId, CancellationToken ct) =>
        db.Orders.Include(o => o.Items).FirstOrDefaultAsync(o => o.Id == orderId, ct);

    public async Task<IReadOnlyList<Order>> ListRecentForCustomerAsync(int customerId, int take, CancellationToken ct) =>
        await db.Orders.AsNoTracking()
            .Where(o => o.CustomerId == customerId)
            .OrderByDescending(o => o.OrderDate)
            .Take(take)
            .ToListAsync(ct);
}

What happened?

• Repository methods encapsulate EF specifics.
• Application calls GetWithItemsAsync instead of composing Include itself.

Practice next

1. Name methods after domain operations not generic GetAll.
2. Keep interfaces in Application; implementations in Infrastructure.
3. Return domain entities or dedicated read DTOs — not IQueryable.
4. Split read methods into IOrderReadRepository using projections only.
5. Add specification pattern for reusable filter objects internally.

Remember

Repositories express domain data operations. Hide Include and filter details inside. Interfaces live in Application layer.

ShopNest order repository

Support portal uses ListRecentForCustomerAsync without copying Include logic in three services.

Outcome: Query changes happen once in OrderRepository.