Why should you care?

ShopNest API controllers should not grow 200-line checkout methods — PlaceOrderHandler encapsulates EF work testably.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

public record PlaceOrderCommand(int CustomerId, List<LineItem> Items) : IRequest<int>;

public class PlaceOrderHandler(ShopNestDbContext db) : IRequestHandler<PlaceOrderCommand, int>
{
    public async Task<int> Handle(PlaceOrderCommand cmd, CancellationToken ct)
    {
        var order = new Order { CustomerId = cmd.CustomerId };
        foreach (var line in cmd.Items)
            order.Items.Add(new OrderItem { ProductId = line.ProductId, Quantity = line.Qty, UnitPrice = line.Price });
        db.Orders.Add(order);
        await db.SaveChangesAsync(ct);
        return order.Id;
    }
}

// Program.cs: builder.Services.AddMediatR(cfg => cfg.RegisterServicesFromAssembly(...));

What happened?

• Controller sends command via IMediator.
• Handler owns EF transaction logic.
• One class per use case simplifies testing and discovery.

Practice next

1. Install MediatR and register assembly scanning.
2. Create one handler per command/query touching EF.
3. Inject DbContext or UnitOfWork into handlers.
4. Add ValidationBehavior validating PlaceOrderCommand before handler runs.
5. Return Result instead of raw int for error propagation.

Remember

MediatR dispatches to EF-backed handlers. Controllers stay thin Send() calls. Handlers align with use cases.

ShopNest checkout handler

POST /orders sends PlaceOrderCommand; handler persists via EF.

Outcome: Checkout logic tested in isolation with InMemory or SQLite.