使用单一泛型仓储时，为何仍需引入Unit of Work模式？

Great question—let’s break this down clearly. You’re right that generic repositories cut down on redundant code, and at first glance, it might seem like a single generic repo would eliminate the need for Unit of Work (UoW). But UoW provides value beyond just fixing inconsistencies from multiple non-generic repos—here’s why it still matters:

Key Reasons to Use UoW with a Single Generic Repository #

1. Consistent Management of DbContext Lifecycle #

Even with a single generic repository, you still need to handle the lifecycle of your DbContext (or whatever ORM context you’re using). Without UoW, you might accidentally instantiate multiple contexts across different parts of your code (e.g., creating a new repo instance in two separate service methods). This can lead to issues like:

• Duplicate entity tracking (the ORM treats two instances of the same entity as separate)
• Failed transactions because changes are spread across disconnected contexts
• Resource leaks if contexts aren’t properly disposed

UoW acts as a central coordinator, ensuring all operations (even with a single generic repo) use the same context instance throughout a business transaction. It also handles disposing the context when work is complete, taking that responsibility off your repository.

2. Atomic Transaction Support #

Suppose you’re using your generic repo to perform multiple linked operations: adding an Order, updating a Customer’s balance, and deleting an old Product. These actions need to succeed or fail together to keep your database consistent.

While you could call SaveChanges() on the repo after each operation, that commits changes incrementally—if the third operation fails, the first two are already persisted. UoW lets you batch all changes and commit them in a single atomic transaction via one SaveChanges() call on the UoW itself. This guarantees that either all changes apply, or none do.

3. Single Responsibility Principle #

A generic repository’s core job should be handling CRUD operations for any entity. Managing context lifecycle, transactions, and coordinating multiple operations? That’s outside its scope.

UoW separates these concerns cleanly:

• Repository: Focuses solely on data access logic (e.g., Add, GetById, Update)
• UoW: Focuses on transaction coordination and context management

This makes your code cleaner, easier to test, and simpler to modify down the line.

4. Future-Proofing for Expansion #

Right now you’re using a single generic repo, but what if later you need to add a specialized repository (e.g., OrderRepository with a custom GetOrdersByCustomerId method)? UoW seamlessly integrates both generic and specialized repos, ensuring they all share the same context and transaction. Without UoW, you’d have to refactor how you manage contexts to support this new repo type.

Example Code Comparison #

Without UoW #

// Generic repo depends directly on DbContext
public class GenericRepository<T> where T : class
{
    private readonly AppDbContext _context;

    public GenericRepository(AppDbContext context)
    {
        _context = context;
    }

    public void Add(T entity) => _context.Set<T>().Add(entity);
    public void Update(T entity) => _context.Set<T>().Update(entity);
    public void Save() => _context.SaveChanges();
}

// Usage: Risk of inconsistent context management
public void ProcessOrder()
{
    var orderRepo = new GenericRepository<Order>(new AppDbContext());
    var customerRepo = new GenericRepository<Customer>(new AppDbContext()); // Oops, different context!

    orderRepo.Add(new Order());
    customerRepo.Update(new Customer { Id = 1, Balance = 500 });

    orderRepo.Save(); // Only saves the order—customer update is stuck in a separate context
}

With UoW #

// UoW manages the context and repos
public class UnitOfWork : IDisposable
{
    private readonly AppDbContext _context;
    public GenericRepository<Order> OrderRepo { get; }
    public GenericRepository<Customer> CustomerRepo { get; }

    public UnitOfWork(AppDbContext context)
    {
        _context = context;
        OrderRepo = new GenericRepository<Order>(_context);
        CustomerRepo = new GenericRepository<Customer>(_context);
    }

    public int SaveChanges() => _context.SaveChanges();
    public void Dispose() => _context.Dispose();
}

// Usage: Consistent context and atomic transactions
public void ProcessOrder()
{
    using (var uow = new UnitOfWork(new AppDbContext()))
    {
        uow.OrderRepo.Add(new Order());
        uow.CustomerRepo.Update(new Customer { Id = 1, Balance = 500 });

        uow.SaveChanges(); // Commits both changes in one atomic transaction
    }
}

Wrap-Up #

While a single generic repository reduces redundancy, Unit of Work adds critical value in managing context lifecycle, ensuring transaction atomicity, adhering to clean code principles, and making your system easier to extend. It’s not just a fix for multi-repo inconsistencies—it’s a tool to keep your data access layer robust and maintainable.

内容的提问来源于stack exchange，提问作者Fred