EF数据库优先下模块级Repository与Unit of Work方案及测试咨询

Hey there! Let's break down your Entity Framework Database-First scenario where you're building module-focused repositories (instead of per-table ones). I’ll walk through two common implementation approaches you might be considering, weigh their pros and cons, suggest a balanced middle ground, and cover how to unit test each setup.

Two Common Module Repository Approaches #

Approach 1: Direct DbContext-Dependent Repositories #

This is the simplest approach: each business module's repository takes a DbContext directly, and you write cross-table queries/updates right inside it. For example:

public class OrderManagementRepository
{
    private readonly AppDbContext _dbContext;

    public OrderManagementRepository(AppDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task<OrderWithCustomerDetails> GetOrderWithCustomerAsync(int orderId)
    {
        return await _dbContext.Orders
            .Include(o => o.Customer)
            .Include(o => o.OrderItems)
            .ThenInclude(oi => oi.Product)
            .Where(o => o.Id == orderId)
            .Select(o => new OrderWithCustomerDetails
            {
                OrderId = o.Id,
                CustomerName = o.Customer.Name,
                TotalAmount = o.OrderItems.Sum(oi => oi.Quantity * oi.Product.Price)
            })
            .FirstOrDefaultAsync();
    }

    public async Task UpdateOrderStatusAsync(int orderId, OrderStatus newStatus)
    {
        var order = await _dbContext.Orders.FindAsync(orderId);
        if (order != null)
        {
            order.Status = newStatus;
            order.UpdatedAt = DateTime.UtcNow;
            await _dbContext.SaveChangesAsync();
        }
    }
}

Pros:

• No extra abstraction overhead: You’re using EF directly, so you can leverage all its features (like Include, projection, change tracking) without workarounds.
• Fast to implement: Great for small-to-medium projects where simplicity beats over-engineering.
• Clear alignment with business logic: The repository directly maps to what your module needs to do.

Cons:

• Tight coupling to DbContext: If your schema changes (e.g., a table is renamed), you’ll have to update every repository that uses it.
• Risk of bloated repositories: As your module grows, the repository might end up handling too many unrelated tasks, violating the single responsibility principle.

Approach 2: Queryable-Wrapped Module Repositories #

Here, you extract reusable table-level query logic into helper classes/extension methods, then your module repository combines these to build cross-table business logic. For example:

// Reusable table-level query extensions
public static class OrderQueries
{
    public static IQueryable<Order> GetActiveOrders(this IQueryable<Order> orders)
    {
        return orders.Where(o => o.Status != OrderStatus.Cancelled);
    }
}

public static class CustomerQueries
{
    public static IQueryable<Customer> GetVerifiedCustomers(this IQueryable<Customer> customers)
    {
        return customers.Where(c => c.IsVerified);
    }
}

// Module repository that combines these queries
public class OrderManagementRepository
{
    private readonly AppDbContext _dbContext;

    public OrderManagementRepository(AppDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task<IEnumerable<OrderWithCustomerDetails>> GetActiveOrdersForVerifiedCustomersAsync()
    {
        return await _dbContext.Orders.GetActiveOrders()
            .Join(_dbContext.Customers.GetVerifiedCustomers(),
                o => o.CustomerId,
                c => c.Id,
                (o, c) => new { o, c })
            .Select(x => new OrderWithCustomerDetails
            {
                OrderId = x.o.Id,
                CustomerName = x.c.Name,
                OrderDate = x.o.OrderDate
            })
            .ToListAsync();
    }
}

A variation of this is using dedicated query providers (e.g., IOrderQueryProvider) instead of static extensions, but the core idea is separating reusable table logic from module-specific combination.

Pros:

• Reusability: Query rules (like "active orders" or "verified customers") can be shared across multiple modules.
• Cleaner separation: The module repository focuses only on combining queries for business needs, not low-level table filtering.
• Easier schema updates: If a table’s filtering logic changes, you only update one query wrapper instead of every repository.

Cons:

• Extra boilerplate: You’ll need to write and maintain these query wrappers, which adds overhead for simple projects.
• Potential for scattered logic: Too many extension methods can become hard to organize as your project scales.

A Balanced, Optimal Approach #

You don’t have to pick one or the other! Mix both approaches based on your needs:

1. Use Approach 1 for simple, one-off cross-table logic: No need to create a wrapper if a query is only used in one module.
2. Extract reusable queries into wrappers (Approach 2): For rules that appear across multiple modules, save time and reduce duplication.
3. Add interfaces to your repositories: Define an IOrderManagementRepository interface for each module repo. This decouples your business logic from the concrete implementation, making it easier to swap out or test.

Example interface setup:

public interface IOrderManagementRepository
{
    Task<OrderWithCustomerDetails> GetOrderWithCustomerAsync(int orderId);
    Task UpdateOrderStatusAsync(int orderId, OrderStatus newStatus);
}

public class OrderManagementRepository : IOrderManagementRepository
{
    // Implementation here...
}

Unit Testing for Both Approaches #

The core goal of testing these repositories is to verify that they execute the right logic, without hitting a real database. Here’s how to do it for each setup:

Testing Approach 1 (Direct DbContext Repos) #

You have two solid options:

Option 1: EF Core In-Memory Database

This simulates a real database environment, so you can test EF-specific behavior (like Include, change tracking, and SaveChanges) accurately:

[TestClass]
public class OrderManagementRepositoryTests
{
    private AppDbContext _dbContext;
    private IOrderManagementRepository _repository;

    [TestInitialize]
    public void Setup()
    {
        // Create an in-memory database with unique name per test
        var options = new DbContextOptionsBuilder<AppDbContext>()
            .UseInMemoryDatabase(databaseName: $"TestDb_{Guid.NewGuid()}")
            .Options;

        _dbContext = new AppDbContext(options);

        // Seed test data
        _dbContext.Customers.Add(new Customer { Id = 1, Name = "John Doe" });
        _dbContext.Orders.Add(new Order { Id = 101, CustomerId = 1, Status = OrderStatus.Pending });
        _dbContext.SaveChanges();

        _repository = new OrderManagementRepository(_dbContext);
    }

    [TestMethod]
    public async Task GetOrderWithCustomerAsync_ReturnsCorrectDetails()
    {
        // Act
        var result = await _repository.GetOrderWithCustomerAsync(101);

        // Assert
        Assert.IsNotNull(result);
        Assert.AreEqual(101, result.OrderId);
        Assert.AreEqual("John Doe", result.CustomerName);
    }

    [TestMethod]
    public async Task UpdateOrderStatusAsync_UpdatesStatusSuccessfully()
    {
        // Act
        await _repository.UpdateOrderStatusAsync(101, OrderStatus.Shipped);

        // Assert
        var updatedOrder = await _dbContext.Orders.FindAsync(101);
        Assert.AreEqual(OrderStatus.Shipped, updatedOrder.Status);
        Assert.IsNotNull(updatedOrder.UpdatedAt);
    }

    [TestCleanup]
    public void Cleanup()
    {
        _dbContext.Database.EnsureDeleted();
        _dbContext.Dispose();
    }
}

Option 2: Mock DbContext with Moq

For simpler logic, you can mock DbSet and DbContext to avoid spinning up an in-memory database:

[TestClass]
public class OrderManagementRepositoryTests
{
    private Mock<AppDbContext> _mockDbContext;
    private IOrderManagementRepository _repository;

    [TestInitialize]
    public void Setup()
    {
        // Seed test data as queryable
        var customers = new List<Customer>
        {
            new Customer { Id = 1, Name = "John Doe" }
        }.AsQueryable();

        var orders = new List<Order>
        {
            new Order { Id = 101, CustomerId = 1, Status = OrderStatus.Pending }
        }.AsQueryable();

        // Mock DbSets
        var mockCustomers = new Mock<DbSet<Customer>>();
        mockCustomers.As<IQueryable<Customer>>().Setup(m => m.Provider).Returns(customers.Provider);
        mockCustomers.As<IQueryable<Customer>>().Setup(m => m.Expression).Returns(customers.Expression);
        mockCustomers.As<IQueryable<Customer>>().Setup(m => m.ElementType).Returns(customers.ElementType);
        mockCustomers.As<IQueryable<Customer>>().Setup(m => m.GetEnumerator()).Returns(customers.GetEnumerator());

        var mockOrders = new Mock<DbSet<Order>>();
        mockOrders.As<IQueryable<Order>>().Setup(m => m.Provider).Returns(orders.Provider);
        mockOrders.As<IQueryable<Order>>().Setup(m => m.Expression).Returns(orders.Expression);
        mockOrders.As<IQueryable<Order>>().Setup(m => m.ElementType).Returns(orders.ElementType);
        mockOrders.As<IQueryable<Order>>().Setup(m => m.GetEnumerator()).Returns(orders.GetEnumerator());

        // Mock DbContext
        _mockDbContext = new Mock<AppDbContext>();
        _mockDbContext.Setup(m => m.Customers).Returns(mockCustomers.Object);
        _mockDbContext.Setup(m => m.Orders).Returns(mockOrders.Object);

        _repository = new OrderManagementRepository(_mockDbContext.Object);
    }

    [TestMethod]
    public async Task GetOrderWithCustomerAsync_ReturnsCorrectCustomerName()
    {
        // Act
        var result = await _repository.GetOrderWithCustomerAsync(101);

        // Assert
        Assert.IsNotNull(result);
        Assert.AreEqual("John Doe", result.CustomerName);
    }
}

This is faster for simple tests but doesn’t handle complex EF features (like Include) as well as the in-memory database.

Testing Approach 2 (Queryable-Wrapped Repos) #

Split your tests into two parts:

1. Test the query wrappers: Verify they filter data correctly.
2. Test the module repository: Verify it combines the wrappers correctly.

Testing Query Wrappers

[TestClass]
public class OrderQueriesTests
{
    [TestMethod]
    public void GetActiveOrders_ExcludesCancelledOrders()
    {
        // Arrange
        var orders = new List<Order>
        {
            new Order { Id = 1, Status = OrderStatus.Pending },
            new Order { Id = 2, Status = OrderStatus.Cancelled },
            new Order { Id = 3, Status = OrderStatus.Shipped }
        }.AsQueryable();

        // Act
        var result = orders.GetActiveOrders().ToList();

        // Assert
        Assert.AreEqual(2, result.Count);
        Assert.IsFalse(result.Any(o => o.Status == OrderStatus.Cancelled));
    }
}

Testing the Module Repository

Use either the in-memory database or Moq approach from Approach 1. The key is to verify that the repository calls the correct query wrappers and returns the expected combined results.

Final Recommendations #

• For small/medium projects: Start with Approach 1 (direct DbContext repos) with interfaces. It’s simple and avoids unnecessary boilerplate.
• For large projects with reusable logic: Mix in Approach 2’s query wrappers to keep your code DRY and maintainable.
• Always use interfaces: They make testing easier and give you flexibility to switch implementations later.

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