EntityFramework Core 中DbContext配置缓存导致测试用例失败问题解析

问题现象

在使用EntityFramework Core进行单元测试时，开发者可能会遇到一个奇怪的现象：当测试用例中使用了依赖单例服务的ValueConverter时，第一个测试用例能够正常运行，但后续测试用例会失败。这种问题特别容易出现在使用InMemory数据库进行测试的场景中。

问题本质

这个问题的根源在于EntityFramework Core对DbContext配置的缓存机制。EF Core为了提高性能，默认会缓存DbContext的配置信息，包括模型构建(OnModelCreating)的结果。这种缓存行为在大多数生产环境中是有益的，但在测试环境中可能会带来意想不到的问题。

具体分析

在示例代码中，ValueConverter依赖于一个单例服务MySingletonConsentService。当第一个测试用例运行时：

1. 创建第一个DbContext实例
2. 执行OnModelCreating构建模型
3. 将ValueConverter与当前单例服务实例绑定
4. 缓存这个配置

当第二个测试用例运行时：

1. 创建新的DbContext实例
2. 由于配置缓存的存在，直接使用缓存的模型配置
3. 但此时ValueConverter仍然引用第一个测试用例中的单例服务实例
4. 导致无法找到新的测试数据，从而抛出异常

解决方案

方案一：禁用服务提供者缓存

最直接的解决方案是在测试环境中禁用服务提供者缓存：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .EnableServiceProviderCaching(false)
        .UseInMemoryDatabase("db");
}

这种方法简单有效，特别适合测试环境。它会强制每次创建DbContext时都重新构建模型，确保使用最新的依赖项。

方案二：自定义缓存键

如果需要在生产环境中处理类似场景，可以使用自定义缓存键的方式：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseModelCacheKeyFactory(new MyCacheKeyFactory())
        .UseInMemoryDatabase("db");
}

private class MyCacheKeyFactory : IModelCacheKeyFactory
{
    public object Create(DbContext context)
    {
        if (context is MyDbContext myContext)
        {
            return (context.GetType(), myContext._singletonConsentService.GetHashCode());
        }
        return context.GetType();
    }
}

这种方法更加精细，它会根据单例服务的状态变化来生成不同的缓存键，从而在需要时自动重建模型。

最佳实践建议

1. 在测试环境中，推荐使用EnableServiceProviderCaching(false)来避免配置缓存带来的问题
2. 在生产环境中，如果确实需要动态改变模型配置，应该使用自定义缓存键的方式
3. 尽量避免ValueConverter依赖可变的外部服务，这种设计本身可能带来维护上的困难
4. 考虑使用拦截器(Interceptor)作为替代方案，它们通常能更好地处理依赖注入的场景

总结

EntityFramework Core的配置缓存机制是为了提高性能而设计的，但在测试环境中可能会带来一些意外行为。理解这一机制的工作原理，并掌握如何适当控制缓存行为，对于编写可靠的测试用例非常重要。通过本文介绍的解决方案，开发者可以灵活应对各种测试场景，确保测试的独立性和可靠性。