Mastering the Repository & Unit of Work (UoW) Patterns

A professional developer never calls _context.SaveChanges() directly in their controller. They use these architectural patterns to decouple the data access from their business logic.

Section 1: The Repository Pattern

The Repository acts as a mediator between the application and the data store. It encapsulates the logic required to access data.

• Decoupling: Your logic doesn't care if data comes from SQL Server, MongoDB, or a JSON file.
• Testability: You can easily mock the repository interface for unit tests.

Section 2: The Unit of Work (The "Atomic" Transaction)

What if your operation involves multiple repositories? (e.g., Creating an Order and Updating Inventory). If one fails, Both must fail. This is where Unit of Work comes in.

// The Unit of Work Interface (Expert Setup)
public interface IUnitOfWork : IDisposable {
    IUserRepository Users { get; }
    IOrderRepository Orders { get; }
    Task CompleteAsync(); // Effectively calls db.SaveChangesAsync()
}

// Why it's useful:
var order = new Order { ... };
_uow.Orders.Add(order);
_uow.Users.UpdatePoints(userId, 10);
await _uow.CompleteAsync(); // Both operations are saved in one transaction