DbContext abstractions with ef core transactions

[XL1TTE]

Enable developers to use an abstraction layer above DbContext by calling WithDbContextAbstraction<TAbstraction, TDbContext>().
This approach allows you to implement IUnitOfWork with any number of IRepository interfaces per DbContext and use this abstraction in handlers instead of directly depending on DbContext.

[jeremydmiller]

@XL1TTE Going to lead with:

1. Yes, this comes up, and I guess
2. I'm deeply unenthusiastic
3. I don't think folks should use that
4. Custom IUnitOfWork implementations are an abomination :-)

And also the very antithesis of how Wolverine is meant to be used. As a bridge for existing code though, sure, I get that.

[XL1TTE]

@jeremydmiller It's primarily about Repository abstraction rather than Unit of Work for me. The challenge arises when packages have intrusive designs that force you to pollute your domain models with persistence-related attributes. This creates a design dilemma:

1. Avoid the library entirely - but this limits your tooling choices
2. Add persistence attributes to domain models - but this couples your domain logic to infrastructure concerns
3. Create separate data access entities - anemic projections of your rich domain models, with a mapping layer between them

If you choose option 3, you inevitably need a bidirectional mapping layer (domain ↔ persistence), which introduces complexity and maintenance overhead.

The real pain point emerges when you use DbContext directly without a repository abstraction, because you come up with ugly code like this in every single handler:

var orderEntity = db.Orders.Find(id);
var order = orderEntity.ToDomain(); // Mapping

// business operations on order

orderEntity.ApplyUpdate(order); // Mapping 
db.SaveChanges();

I get it why repository abstraction is opinionated with modern efCore, but the cases like this one above is actually kind a difficult for me to work around w/o them.

P.S: WithDbContextAbstraction will only work if DbContext itself implements the interface, which means that it will not support abstractions that wraps around DbContext for example.

P.P.S: Would be happy to hear some insights about that.

[jeremydmiller]

@XL1TTE This: https://jeremydmiller.com/2025/02/27/we-dont-need-no-stinkin-repositories-and-other-observations-on-dotnetrocks/

[jeremydmiller]

@XL1TTE I'll take this in, but to be more idiomatic in Wolverine, you could use the EF Core transaction middleware and other integration and write code like this:

public static void Handle(UpdateOrder command, [Entity] Order orderEntity)
{
    // do whatever to mutate the Order
}

// Wolverine takes care of  both loading the Order and SaveChangesAsync & the outbox for that matter

The Wolverine way leads to simpler code, business logic being decoupled from infrastructure, more testable code, and less layering hoops to jump through