> Great post. Now let's do C# because if I see a repository pattern doing nothing but calling Entity Framework under the hood again I'm going to rip the planet in half

Your comment shows a hefty amount of ignorance. Repositories wrap Entity Framework because Entity Framework's DbContext & Co are notoriously complicated to mock and stub.

Once you wrap EF stuff with a repository that implements an interface, that problem vanishes and all your code suddenly is unit testable.

We don't really have this problem in .NET 8, we mock stuff just fine using an in-memory database provider.

But I admit my tone missed the mark. It may have been much harder to do in the past, or maybe I'm missing some nuance.

But also at this point why not just have your DbContext directly implement an interface that you can mock? Surely that must be more straightforward than adding an entire abstraction layer, that you have to extend with each new usage scenario, and without sacrificing implicit transactionality.

> We don't really have this problem in .NET 8, we mock stuff just fine using an in-memory database provider.

No, you don't. At best in-memory databases represent a test double that you can use in integration tests.

If you need to write unit tests, EF leaves you no better option than to add repositories to abstract out everything and anything involving DbContext.

What you dont like

  public class Repository<TEntity> : IRepository<TEntity> where TEntity : class
  {
      public async Task Add(TEntity entity)
      {
          _context.Add(entity);
          await _context.SaveChangesAsync();
      }
  }

everywhere?