Clean Architecture: Why I Stopped Injecting DbContext Directly

[Lomanu4]

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.

Пожалуйста Авторизируйтесь или Зарегистрируйтесь для просмотра скрытого текста.