C_SHARP_SKILLS/docs/unit-of-work-pattern.md

Unit of Work Pattern Notes

Use the Unit of Work pattern when a C#/.NET application needs one clear transaction boundary across multiple repository operations.

Core idea

A Unit of Work owns or coordinates one EF Core DbContext. Repositories use that same context to stage changes. The application service or controller calls SaveChangesAsync once at the end of the logical operation.

Recommended shape

AppDbContext
  ├─ DbSet<Customer>
  ├─ DbSet<Order>
  └─ DbSet<Product>

IGenericRepository<TEntity>
GenericRepository<TEntity>

IUnitOfWork
  ├─ Customers
  ├─ Orders
  ├─ Products
  └─ SaveChangesAsync()

Best practices

• Register DbContext, repositories, and Unit of Work with compatible lifetimes, usually scoped in ASP.NET Core.
• Keep one shared context per Unit of Work.
• Let repositories stage changes; let Unit of Work commit changes.
• Prefer async EF Core methods with cancellation tokens.
• Use AsNoTracking for read-only queries.
• Prefer typed Include expressions over string include paths.
• Keep business rules in services/domain methods, not generic repositories.
• Avoid mixing direct DbContext access and Unit of Work access in the same workflow.

When not to use it

Do not add a custom Unit of Work just for ceremony. EF Core DbContext already provides Unit of Work behavior. A custom abstraction is most useful when the project has a repository convention, a testing boundary, or complex operations spanning multiple repositories.