Clean Architecture: Why I Stopped Injecting DbContext Directly

Javid KoluRazhan — Fri, 16 May 2025 11:36:20 +0000

In my early days with ASP.NET Core, I often injected DbContext directly into controllers or services. It worked — but over time, things got messy: hard-to-test code, tight coupling, and business logic leaking into the infrastructure.

Here’s what I do now:
I use the Repository Pattern + Unit of Work to abstract away the data access logic. My services talk to interfaces like IOrderRepository, not DbContext.

public interface IOrderRepository
{
    Task<Order> GetByIdAsync(Guid id);
    void Add(Order order);
}

Benefits:

Easier unit testing (mocking repositories)
Clear separation of concerns
Domain logic is not mixed with EF-specific code

Tip:
If you're working on a medium-to-large project, try isolating EF Core behind interfaces. It’s a small change that pays off big time.

DEV Community: Javid KoluRazhan

Clean Architecture: Why I Stopped Injecting DbContext Directly