DEV Community: Paulo Pozeti

Why you should abstract EF's DBContext

Paulo Pozeti — Tue, 07 Apr 2026 09:49:19 +0000

Every article, old or new, about Entity Framework tells you the same thing: DbContext is already a Unit of Work, DbSet is already a Repository, and if you abstract over them you're just creating abstraction over abstraction. I think they're answering the wrong question.

Others say you should only do if the app is big or logic is complex. I think it doesn't matter the size of your organization or product! You should always abstract infrastructure.

Let's see if I can convince you.

Current misconception

If you search right now about EF DBContext Repository Pattern, you are likely to find the following:

Argues that DbContext is already a Unit of Work and DbSet is already a Repository. Adding another layer is redundant abstraction over abstraction. — Gunnar Peipman
A thorough analysis concluding that the traditional repository pattern adds complexity without benefit — Jon P Smith (The Reformed Programmer)
The Repository Pattern is Dead. EF Core Killed It. — Yaseer Arafat
Discusses how developers fall into the trap of wrapping DbContext, ending up with more code, less flexibility, and no real benefit. — Julio Casal
And the list goes on...

When we summarize the arguments from most of those posts, most of them can fall into the following categories:

DbContext is the Unit of Work; DbSet is the Repository. Wrapping them is abstraction over abstraction.
You lose EF IQueryable composition, eager/lazy loading, change tracking, raw SQL, bulk operations all get hidden or crippled.
"Swap out the ORM" never happens. Too risky to swap ORMs in real projects.

I will talk about why those things aren't entirely true.

Fallacy #1: Abstraction over abstraction

The people making this argument are answering the wrong question. They're asking:

Should I abstract Entity Framework?

When the real question is:

Should my domain/application layer know how or where data is stored?

The Repository pattern was never about wrapping an ORM!

The original https://deviq.com/design-patterns/repository-pattern/ is defined as a collection-like abstraction that hides persistence completely, lives in the domain layer as an interface, and speaks the language of the business. It predates ORMs and EF!

Saying "DbContext is already a repository" combines two different things:

A data access mechanism (what DbContext is)
A domain boundary contract (what a Repository is supposed to be)

A DbContext speaks the language of SQL, change tracking, Include(), IQueryable, and migrations. A proper repository speaks the language of your domain: GetActiveCustomersByRegion(), FindOverdueInvoices().

DbContext is Microsoft's abstraction, not yours

Being too reliant on DbContext and DbSet<T> is giving too much power to the ORM library. They are owned by Microsoft, not your application!
You don't control them. You don't own their interface. They can change across versions.

Your domain contract (IOrderRepository) is yours. You define it. You control what it exposes. You decide when it changes. This is the difference between:

Coupling to a third-party API surface you don't control
Depending on a contract you own that happens to be implemented by EF today

So even though Microsoft tries their best in keeping contracts backwards compatible, we've seen breaking changes between EF versions, like:

EF Core 3.0 breaking changes

FromSql renamed to FromSqlRaw / FromSqlInterpolated
DbQuery removed — replaced by keyless entity types
Default string length changed in the backing model
DbContext.Entry behavior changed for detached entities

EF Core 6.0 breaking changes

DbSet no longer implements IAsyncEnumerable — code casting DbSet to IAsyncEnumerable broke

Do you still want to have to change your whole application whenever a contract changes?

Fallacy #2: Lose EF specific features

This argument fundamentally misunderstands what abstraction means. Abstraction doesn't mean you stop using EF features. It means you stop exposing them.

The repository implementation still uses every EF Core feature available. Include(), ThenInclude(), AsSplitQuery(), change tracking, ExecuteUpdate(), raw SQL, everything. The abstraction is the interface, not the implementation.

The biggest "feature" people claim you lose is leaking IQueryable to consumers. But as https://ardalis.com/avoid-dbcontext-iqueryable-proliferation/ mentioned, letting IQueryable proliferate through your app is actively harmful:

Any consumer can compose any arbitrary query — there's no control over what SQL hits your database
Query logic gets scattered across controllers, services, and middleware instead of being centralized
You can't optimize, cache, or audit queries you don't know exist
You can't swap the data source for specific queries (cache, Dapper, API) because consumers are writing LINQ everywhere

Encapsulating IQueryable inside the repository means:

All query logic is in one place: easier to optimize, profile, and review
The domain gets exactly the data it needs: no over-fetching, no surprise N+1s

You don't lose EF features by abstracting. You stop accidentally exposing EF's entire surface area as your application's data access contract. The implementation uses everything EF offers. The interface exposes only what the domain actually needs.
That's not losing features. That's engineering.

Fallacy #3: You will never replace EF

This is the argument I hear most, and it misses the point entirely.

Even though I agree it is hard for business to move from, say MongoDB to SQL Server, it's not impossible.
What is more likely to happen is moving from EF6 to EF Core.

That happened and if you were too entangled with EF6 in your services, controllers, you probably struggled way more than necessary!

"You will never replace EF" is an argument about probability. But abstraction isn't insurance against a single catastrophic event. It's a daily engineering benefit that makes your code testable, traceable, flexible query-by-query, and resilient to the breaking changes Microsoft ships with every major version.

Conclusion

The debate was never about using Entity Framework's DBContext. It was about whether your business logic should know where its data comes from.

A repository interface is a few lines of code. Behind it, you can use every feature EF offers, and when EF ships its next round of breaking changes, you fix the implementation, not the entire application.

If you're working in a codebase where DbContext is threaded through controllers and services, you don't have to rewrite everything tomorrow. Start with one aggregate. Define the interface. Move the queries behind it. See how it feels. The cost is small, and once you've done it, you won't want to go back.

I hope I've convinced you, but if I haven't, tell me why in the comments!

Testing is the most important piece in software engineering

Paulo Pozeti — Sun, 29 Mar 2026 11:59:51 +0000

You might think I'm crazy with such statement but if I had to summarize what my experience is, that is the only thing I can think about.

Let's go through some story of my life, shall we?

The past

I started my career on a pretty big product. At first, I couldn't understand much but after a few months it became apparent what the software development flow was:

Customer/product came up with a Change Request (a word document containing one or more product features).
Product Architects from different areas would analyze the CR document and find out if their areas could be impacted. Interestingly they would do that on a meeting where each could validate their assumptions.
PA would then write a High-Level Architecture Document, which would link to the CR document, and describe what is the effect of the requirement against a particular part of the system.
The HLD would then move to tech leads + seniors for review, clarify anything doubts and get a feel for the code involved. The outcome of this was a Detailed Design document. This could have a few pseudo-code ideas and even the exact change to be made.
Then a developer would pick it up, implement, design unit tests, test and mark task as delivered.

Ok, so, classic waterfall process but apart from the developer testing it, how come was that different than most businesses do today?

They had a separate QA team. But not a simple QA team, they knew the system from top to bottom. I didn't mention, on purpose, that they were also part of the PA meeting and also played a critical in creating tests that were cross areas.

It was always expected for developers to validate their changes in a level that QA's do today. You should indeed check for all the permutations of the modified code and take your time testing them. In doubt? Two things: simplify your solution or test the hell of it.

The QA team would have their own test process, they didn't work close to developers because they weren't worried about the ifs or elses. They always had a holistic view of the system. They knew that if devs are touch the customer registration flow, they would test that with everything they knew!

Back to now

What is different now? Why does it feel that systems nowadays are flaky and with every new version there's always something broken?

I don't have the-all-seeing-eye, but in my past experiences it is clear that we have less and less testing involved as part of the Software Development Life Cycle and another critical point: software companies are leaner than ever!

We now have tools to automate everything. We can easily create tests in all levels, in a matter of seconds! Thanks Claude Code. But why are we still lacking confidence to deploy to production when we make a change?

Problem(s)

Tests were never about exercising the code. It's not about clicking around and make sure your breakpoint gets hit and nothing breaks.

It's not getting that 80% coverage and testing every single branching of logic.

It's also not about writing unit tests where you control every single step of the test. We have test abusers, leveraging Moq and all sort of tools for that.

I've seen more and more code worried about applying the DRY principle and they forget that tests should be simple, visible and about validating our understanding of how things should work.

(possible) Solution

Tests exist to validate our assumptions about something. Because of that, make sure to write tests that:

Are easy to understand
Have meaning and clear intent
Asserts everything (and more!!!) and explain why
You choose the right type of test for your scenario

Conclusion

Let me show you what I mean with some concrete examples.

Bad: Testing code branches, not assumptions

  [Fact]
  public void Register_WhenEmailIsNull_ThrowsException()
  {
      var mockRepo = new Mock<IUserRepository>();
      var mockEmail = new Mock<IEmailService>();
      var mockLogger = new Mock<ILogger<RegistrationService>>();
      var sut = new RegistrationService(mockRepo.Object, mockEmail.Object, mockLogger.Object);

      Assert.Throws<ArgumentNullException>(() => sut.Register(null, "password123"));
  }

This test mocks everything, exercises one branch, and tells you nothing about whether registration actually works.
It's testing that an if statement exists.

Better: Validating your understanding of the behavior

  [Fact]
  public void New_user_can_register_and_receives_welcome_email()
  {
      // Arrange - use real components; only fake what crosses system boundaries
      var db = new TestDatabase();
      var emailInbox = new FakeEmailInbox();
      var service = new RegistrationService(
          new UserRepository(db.Connection),
          new FakeEmailService(emailInbox),
          NullLogger<RegistrationService>.Instance);

      // Act
      var result = service.Register("jane@example.com", "SecureP@ss1");

      // Assert — each assertion documents a business expectation
      Assert.True(result.Succeeded, "Registration should succeed for a valid new user");

      var savedUser = db.Query<User>("SELECT * FROM Users WHERE Email = @Email",
          new { Email = "jane@example.com" });
      Assert.NotNull(savedUser); // The user must actually be persisted
      Assert.True(savedUser.IsActive, "New users should be active immediately");

      var email = emailInbox.Single();
      Assert.Equal("jane@example.com", email.To);
      Assert.Contains("Welcome", email.Subject); // We promised a welcome email
  }

Notice the difference. This test reads like a specification: a new user registers, gets persisted, is active, and receives a welcome email. Every assertion has intent. If any of these break, you know exactly which assumption was wrong.

Testing across boundaries, like that QA team did:

[Fact]
public void Updating_product_price_does_not_change_price_in_existing_carts()
{
    var db = new TestDatabase();
    var productId = db.Insert(new Product { Name = "Widget", Price = 9.99m });
    var cartId = db.Insert(new Cart { CustomerId = 42 });
    db.Insert(new CartItem { CartId = cartId, ProductId = productId, PriceAtTimeOfAdd = 9.99m });

    var catalog = new CatalogService(new ProductRepository(db.Connection));

    catalog.UpdatePrice(productId, newPrice: 14.99m);

    // Product price updated
    var product = db.Query<Product>(productId);
    Assert.Equal(14.99m, product.Price);

    // But the cart must be untouched — the customer saw 9.99 when they added it
    var cartItem = db.Query<CartItem>("WHERE CartId = @CartId", new { CartId = cartId });
      Assert.Equal(9.99m, cartItem.PriceAtTimeOfAdd,
          "Carts must snapshot the price at add-time; a catalog update should never silently change what a customer
  expects to pay");
}

That QA team from my past would have caught this. They knew that if you touch the catalog, you check the cart, checkout, invoicing — everything downstream. Two different teams own these areas, and neither writes tests for the other's assumptions. That's exactly where production bugs hide.

So, what should you take away?

Stop relying on coverage.
Stop mocking everything.
Start writing tests that describe what your system promises to do!
Verify those promises end to end.

If your test reads like a spec that a new team member could understand on day one, you're on the right track.

Tests are not about exercising code. They're about proving you understand what your software is supposed to do and that it actually does it.

Interface definition has never been so important!

Paulo Pozeti — Sat, 21 Mar 2026 10:20:45 +0000

Problem

I know you might be looking at this and thinking: interface definition has always been important! And I agree to that, but that's not what I'm seeing on the ground.

With the increase of tutorials of prescribed architectures (hexagon, clean...), it's clear to see that the only intent for interfaces now is to create a boundary between layers, instead of a boundary of meaning.

A boundary between layers says 'this code lives here.' A boundary of meaning says 'this is what I can do and why.'

What I mean by that? Well, lets look at a simple example I found on the web:

// https://github.com/jasontaylordev/CleanArchitecture/blob/main/src/Application/Common/Interfaces/IApplicationDbContext.cs
public interface IApplicationDbContext
{
    DbSet<TodoList> TodoLists { get; }

    DbSet<TodoItem> TodoItems { get; }

    Task<int> SaveChangesAsync(CancellationToken cancellationToken);
}

IApplicationDbContext doesn't have a specific job. Its only purpose is to give you a limited number of actions against EF DbSet's. And if you can't see any usings in that about EntityFramework is because that is hidden via global usings.
So all they are doing is "I'm going to define an interface, that doesn't abstract anything, doesn't have any meaning other than represent some other layer's capabilities".

Why does this matter now?

I don't know if you noticed, but we are entering a new phase of software engineering. We are shifting from trying to find existing NuGet packages that does the work we need to now use AI that generates the minimum amount of code needed to suffice our requirements.

But the problem is that AI often does two things:

Perpetuate the "meaningless" interface approach
Might entangle your code with other packages

To me, the 2nd point isn't as critical because that happens nowadays anyway. But the 1st point we must think about and address properly!

Solution: meaningful interfaces

I picked the first example I could find on the internet when I searched for "clean architecture template", luckily that is also the easiest one to fix!

If we look back at IApplicationDbContext, and I didn't mention it as a problem, but we can see that it holds two meanings:

State management: creating/updating saving changes
Queries: accessing the raw DbContext to do whatever query

Since that interface holds two meanings we already know what we gotta do, let's split them.

State management abstraction

First lets create a new interface and name it very explicitly:

// Explicit intent which is to handle Todo's state. We can only pull the ToDo or add one. Maybe in the future we can also remove it.
public interface ITodoStateData
{
    void NewTodoList(TodoList newItem);

    TodoList GetTodoList(int id);
}

// Saving changes isn't part of the ITodoStateData, it belongs to something else.
public interface IUnitOfWork
{
    Task<int> SaveChangesAsync(CancellationToken cancellationToken);
}

As you can see, now those interfaces have a whole new meaning. Just by looking at the name of the interface you can grasp what they should be doing.

Then when you implement those, you can go nuts on EF capabilities.

An example would be:

public class ApplicationDbContext : DbContext, ITodoStateData, IUnitOfWork
{
    // Here you would have your dbsets as usual...
    public DbSet<TodoList> TodoLists => Set<TodoList>();
    public DbSet<TodoItem> TodoItems => Set<TodoItem>();

    // ITodoStateData members
    public void NewTodoList(TodoList newItem) => TodoLists.Add(newItem);
    public TodoList GetTodoList(int id) => TodoLists.First(x=>x.Id == id);

    // IUnitOfWork SaveChangesAsync just works out of the box
}

That only solves the state management problem, now let's go to the query one.

Queries

For queries, many people are now thinking that exposing the DbContext is the best approach as it gives you most of the flexibility. That is true but it doesn't give you reusability and meaning.

To me, queries can fall into two buckets:

It fulfills an API request or all the data for a specific view
It's a shared piece of logic that must be true all the time

The approach of having DbContexts is fine for the bucket #1 but falls short on #2.

How I would solve this problem is by, guess what, creating more interfaces with meaning!

// When you read: Todos list page, what comes to your mind?
public interface ITodosListPage
{
   Task<PaginatedList<TodoItemBriefDto>> Handle(GetTodoItemsWithPaginationQuery request, CancellationToken cancellationToken) 
}

So now, that interface is very specific to the page that shows a list of Todos!
Now where you implement this? Can be in ApplicationDbContext itself, or another class in the Infrastructure project that has access to ApplicationDbContext.

If you have sharp eyes you might ask the question: hold on, you are passing GetTodoItemsWithPaginationQuery down to Infrastructure?
Ok, so you are paying attention. How you solve this is by creating a more general abstraction for the "pagination data" that your infrastructure can fulfill. I shall write about this later!

Conclusion

We should be creating interfaces to ensure proper meaning between layers and also be very explicit about their intent!
It's completely fine to have smaller but full of intent interfaces. Then have all of those implemented by a single class. Especially when they are all tied to external packages like EF!
Another thing worth saying is that once you've set up this pattern in your code base, AI will definitely pick this pattern up and give you more aligned solutions.
As with anything, this doesn't come for free. More interfaces mean you may end up with multiple implementors of the same logic. But to be honest, this already happens with the queries being duplicated everywhere anyway.