ASP.NET Core全局视图辅助类最佳实践及依赖注入相关疑问

静态类确实不是这类场景的理想选择——它不利于测试、依赖管理，还容易因为生命周期问题导致资源泄漏。更合适的做法是创建一个可注入的服务类，结合缓存和数据库访问来实现需求：

1. 定义服务接口与实现 #

先抽象出站点配置的服务接口，再实现具体的业务逻辑（包含缓存和数据库交互）：

// 服务接口
public interface ISiteConfigService
{
    Task<SiteConfig> GetCurrentConfigAsync();
}

// 具体实现
public class SiteConfigService : ISiteConfigService
{
    private readonly AppDbContext _dbContext;
    private readonly IMemoryCache _cache;
    private const string _cacheKey = "SiteConfig_Current";

    // 通过构造函数注入依赖
    public SiteConfigService(AppDbContext dbContext, IMemoryCache cache)
    {
        _dbContext = dbContext;
        _cache = cache;
    }

    public async Task<SiteConfig> GetCurrentConfigAsync()
    {
        // 优先从缓存读取
        if (_cache.TryGetValue(_cacheKey, out SiteConfig config))
        {
            return config;
        }

        // 缓存未命中时查询数据库，这里假设取最新的配置记录
        config = await _dbContext.SiteConfigs
            .OrderByDescending(c => c.CreatedAt)
            .FirstOrDefaultAsync() ?? new SiteConfig(); // 提供默认配置兜底

        // 将结果存入缓存，设置过期时间（比如1小时）
        _cache.Set(_cacheKey, config, TimeSpan.FromHours(1));

        return config;
    }
}

// 站点配置实体类
public class SiteConfig
{
    public int Id { get; set; }
    public string SiteName { get; set; }
    public string LogoUrl { get; set; }
    public DateTime CreatedAt { get; set; }
}

2. 注册服务到依赖注入容器 #

在项目的启动配置文件（比如Program.cs）中，把服务和缓存组件注册到DI容器：

var builder = WebApplication.CreateBuilder(args);

// 注册DbContext（根据你的实际配置调整）
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

// 注册站点配置服务和内存缓存
builder.Services.AddScoped<ISiteConfigService, SiteConfigService>();
builder.Services.AddMemoryCache();

3. 在业务代码中注入使用 #

在控制器、视图组件或者页面中，通过构造函数注入服务并调用：

public class HomeController : Controller
{
    private readonly ISiteConfigService _siteConfigService;

    public HomeController(ISiteConfigService siteConfigService)
    {
        _siteConfigService = siteConfigService;
    }

    public async Task<IActionResult> Index()
    {
        var config = await _siteConfigService.GetCurrentConfigAsync();
        ViewData["SiteName"] = config.SiteName;
        ViewData["LogoUrl"] = config.LogoUrl;
        return View();
    }
}

• 静态类的生命周期是应用域级别的，无法通过DI容器管理依赖，测试时很难Mock替换数据库或缓存实现。
• 静态类如果持有DbContext实例，会导致上下文无法被正确释放，引发数据库连接泄漏、状态混乱等问题。
• 缓存和业务逻辑耦合在静态类中，后续修改或扩展会非常麻烦。

如果因为特殊场景必须使用静态类，可以通过服务定位器模式临时解决依赖注入问题，但这是反模式，会增加代码耦合度：

public static class SiteUtilities
{
    private static IServiceProvider _serviceProvider;

    // 应用启动时初始化服务提供者
    public static void Initialize(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public static async Task<SiteConfig> GetSiteConfigAsync()
    {
        // 创建服务作用域，确保DbContext能被正确释放
        using var scope = _serviceProvider.CreateScope();
        var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        var cache = scope.ServiceProvider.GetRequiredService<IMemoryCache>();

        const string cacheKey = "SiteConfig_Current";
        if (cache.TryGetValue(cacheKey, out SiteConfig config))
        {
            return config;
        }

        config = await dbContext.SiteConfigs
            .OrderByDescending(c => c.CreatedAt)
            .FirstOrDefaultAsync() ?? new SiteConfig();

        cache.Set(cacheKey, config, TimeSpan.FromHours(1));
        return config;
    }
}

// 在Program.cs中初始化
var app = builder.Build();
SiteUtilities.Initialize(app.Services);

注意：这种方式虽然能运行，但会让代码的可测试性和可维护性大幅下降，仅建议在极端场景下临时使用。

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