Why should you care?

ShopNest CheckoutService calculates totals, validates stock, calls repositories, commits once — controller only maps HTTP to service call.

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 class CheckoutService(IUnitOfWork uow, IInventoryService inventory)
{
    public async Task<Result<int>> PlaceOrderAsync(PlaceOrderRequest req, CancellationToken ct)
    {
        if (!await inventory.ReserveAsync(req.Lines, ct))
            return Result.Fail("Insufficient stock");

        var order = new Order { CustomerId = req.CustomerId };
        foreach (var line in req.Lines)
            order.Items.Add(new OrderItem { ProductId = line.ProductId, Quantity = line.Qty, UnitPrice = line.Price });

        await uow.Orders.AddAsync(order, ct);
        await uow.SaveChangesAsync(ct);
        return Result.Ok(order.Id);
    }
}

What happened?

• Service validates business rules before EF Add.
• UnitOfWork coordinates persistence.
• Controller stays thin — no DbContext in controller.

Practice next

1. Place use-case classes in Application/Services or Handlers.
2. Inject abstractions not DbContext in controllers.
3. Return Result or domain errors not exceptions for business failures.
4. Extract pricing policy IPricingService injected alongside repositories.
5. Wrap PlaceOrderAsync in explicit transaction via UnitOfWork.

Remember

Services orchestrate business + data access. SaveChanges at use case boundary. Keep EF out of controllers.

ShopNest checkout service

CheckoutService reserves stock and creates order before payment gateway call from controller.

Outcome: Business rules centralized — not duplicated in API and background job.