Yaseer Arafat

🪦 The Repository Pattern is Dead. EF Core Killed It.

Let’s stop pretending.

🚩 Introduction

The Repository Pattern has been a staple of .NET development for years, promising abstraction and testability. But with Entity Framework Core (EF Core) evolving rapidly, is this pattern still relevant—or just unnecessary ceremony? In this post, I’ll argue that for most modern applications, EF Core’s capabilities render the Repository Pattern obsolete. Agree or disagree? Read on and let’s debate.

1744799768886

⚰️ Why Wrapping EF Core is (Usually) Pointless

In 2025, if you’re still wrapping EF Core with a UserRepository that does nothing but call DbContext.Users, you’re not adding value—just ceremony.

You’re not writing a “pattern.” You’re adding friction.

🏛️ EF Core is Already Your Repository

EF Core provides everything the Repository Pattern promises—and more:

✨ IQueryable magic: Compose queries, defer execution, and chain filters.
🧑‍🔬 Unit of Work: DbContext manages transactions natively.
🔄 Change Tracking: Track and persist changes automatically.
🗂️ Projection, Pagination, Filtering: All built-in, with LINQ and more.
📝 Raw SQL when you really need it: Drop down for performance or complex queries.

Compare this:

// The "classic" repository pattern
public class UserRepository : IUserRepository {
    private readonly MyDbContext _ctx;
    public UserRepository(MyDbContext ctx) => _ctx = ctx;

    public Task<List<User>> GetAllAsync() => _ctx.Users.ToListAsync();
}

To simply:

// Using EF Core directly
await dbContext.Users.ToListAsync();

Which adds more value?

🤔 What Are You Really Abstracting?

Most repositories today are glorified .ToListAsync() wrappers—adding zero value while actually hiding EF Core’s power and flexibility.

🧹 You Don’t Need a Repository. You Need Clean Use Cases.

Let EF Core do what it does best.
Stop suffocating your architecture with outdated patterns.

Instead, focus on clear, use-case-driven services that coordinate your business logic, and let DbContext shine for data access.

⚖️ But Wait—Are There Exceptions?

Yes, sometimes the Repository Pattern still makes sense:

Multiple Data Sources: If you need to swap out EF Core for another provider, a repository can help.
Legacy or Complex Systems: Abstracting persistence may simplify gnarly dependencies.
Testing Without EF Core: Some prefer mocking repositories over using EF’s in-memory provider.
Domain-Driven Design: Sometimes repositories are part of the ubiquitous language.

But for most CRUD apps? Direct EF Core is simpler, clearer, and just as testable (with the right patterns).

➕ Pros and Cons at a Glance

Pros of Skipping the Repository Pattern:

Less code and ceremony.
Full access to EF Core features.
Better performance (no unnecessary abstraction layers).

Cons (and When to Consider a Repository):

Swapping data sources is harder.
May impact pure DDD approaches.
Some teams prefer the discipline (and test boundaries) repositories enforce.

🗣️ Agree or Disagree? Let’s Debate!

What’s your experience?

Do you still use the Repository Pattern with EF Core?
If so, why? If not, what finally convinced you to stop?

Share your thoughts in the comments below, or link to your own posts! Let’s push .NET architecture forward—together.