.NET MVVM模式下如何避免重复注入大量DbContext

Great question! I totally get the frustration of repeating that constructor injection code across every PageModel as your app grows. Let's go through some practical solutions, and also address your question about using a singleton for DbContext.

1. 创建基础PageModel类（最直接的解决方案） #

The simplest way to eliminate that repetitive code is to create a base class that handles the DbContext injection, then have all your PageModels inherit from it. Here's how that works:

First, define your base class with the DbContext injected:

public class BasePageModel : PageModel
{
    // 设为protected，让子类可以直接访问
    protected readonly ApplicationDbContext _dbContext;

    public BasePageModel(ApplicationDbContext dbContext)
    {
        _dbContext = dbContext;
    }
}

然后，所有PageModel都继承这个基类，只需把DbContext传递给基类构造函数即可：

public class IndexModel : BasePageModel
{
    public IndexModel(ApplicationDbContext dbContext) : base(dbContext)
    {
        // 无需再重复定义_dbContext，直接使用基类的实例
    }

    // 页面逻辑示例：
    public async Task OnGet()
    {
        var products = await _dbContext.Products.ToListAsync();
        // ...
    }
}

这样一来，DbContext的注入逻辑只需在基类中写一次，所有子类都能直接使用，大幅减少了冗余代码。

2. 引入Repository模式（更解耦的方案） #

如果你想进一步解耦PageModel与DbContext的直接依赖，可以考虑使用Repository模式。它将数据访问逻辑封装在专门的类中，让PageModel只依赖这些仓储类，而不是直接依赖DbContext。

比如先定义仓储接口和实现：

public interface IProductRepository
{
    Task<List<Product>> GetAllProductsAsync();
    Task<Product?> GetProductByIdAsync(int id);
    // 添加其他数据操作方法
}

public class ProductRepository : IProductRepository
{
    private readonly ApplicationDbContext _dbContext;

    public ProductRepository(ApplicationDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task<List<Product>> GetAllProductsAsync()
    {
        return await _dbContext.Products.ToListAsync();
    }

    public async Task<Product?> GetProductByIdAsync(int id)
    {
        return await _dbContext.Products.FindAsync(id);
    }
}

然后在Program.cs/Startup.cs中注册仓储：

builder.Services.AddScoped<IProductRepository, ProductRepository>();

现在你的PageModel可以注入仓储类，而非直接注入DbContext：

public class IndexModel : PageModel
{
    private readonly IProductRepository _productRepo;

    public IndexModel(IProductRepository productRepo)
    {
        _productRepo = productRepo;
    }

    public async Task OnGet()
    {
        var products = await _productRepo.GetAllProductsAsync();
        // ...
    }
}

这不仅减少了重复代码（如果多个PageModel使用同一个仓储），还让代码更易于测试——你可以轻松模拟仓储类，无需依赖真实的DbContext。

关于单例模式的疑问：绝对不要这么做！ #

很高兴你问到这个点，这非常关键：绝对不要将ApplicationDbContext注册为单例，原因如下：

• DbContext是有状态的：它会跟踪实体变更、维护内部缓存，并且本身不是线程安全的。
• 如果使用单例DbContext，多个并发请求会共享同一个实例，导致竞态条件、实体状态混乱和数据完整性问题。
• DbContext默认且推荐的生命周期是Scoped——即每个HTTP请求对应一个实例。这样能确保每个请求拥有独立的DbContext，避免并发问题。

总结 #

• 若想快速减少冗余代码，优先使用基础PageModel类方案。
• 若追求更好的关注点分离和可测试性，可以结合基础类与Repository模式。
• 务必避免单例DbContext——它会给应用带来难以调试的问题。

内容的提问来源于stack exchange，提问作者J. Doe