Npgsql.EntityFrameworkCore.PostgreSQL 数据源配置状态泄漏问题解析

问题背景

在使用 Npgsql.EntityFrameworkCore.PostgreSQL 时，开发人员可能会遇到一个看似奇怪的现象：当通过 ConfigureDataSource 方法配置数据源时，不同的服务提供者（ServiceProvider）之间会出现状态泄漏。具体表现为，即使在不同服务集合中配置了不同的用户名（如"foo"和"bar"），最终获取的数据库连接字符串却可能相同。

技术原理

这个问题的根源在于 EF Core 的设计机制和 Npgsql 的实现方式：

1. EF Core 的缓存机制：EF Core 会基于配置信息（如连接字符串）来缓存数据源（DataSource）。这种设计初衷是为了优化性能，避免重复创建相同配置的数据源。

2. Npgsql 的实现限制：ConfigureDataSource 方法接受一个 lambda 表达式作为参数，而 EF Core 无法感知和比较 lambda 表达式内部的具体配置变化。因此，它只能基于外部的连接字符串来进行缓存。

3. 哈希比较的局限性：EF Core 尝试通过哈希比较来识别不同的配置，但对于像 lambda 表达式这样的复杂配置项，这种机制无法正常工作。

问题重现

当开发者按照以下模式编写代码时，就会出现问题：

// 第一个服务集合配置
services1.ConfigureDbContext<TestDbContext>(options => 
    options.UseNpgsql(builder => 
        builder.ConfigureDataSource(dataSourceBuilder => 
            dataSourceBuilder.ConnectionStringBuilder.Username = "foo")));

// 第二个服务集合配置
services2.ConfigureDbContext<TestDbContext>(options => 
    options.UseNpgsql(builder => 
        builder.ConfigureDataSource(dataSourceBuilder => 
            dataSourceBuilder.ConnectionStringBuilder.Username = "bar")));

尽管在两个独立的服务集合中配置了不同的用户名，但由于缓存机制的限制，最终可能只会使用第一个配置。

解决方案

针对这个问题，官方推荐的做法是：

1. 避免在 ConfigureDataSource 中做可变配置：不要在 lambda 表达式中修改会变化的配置项。

2. 手动创建 NpgsqlDataSource：如果需要不同的配置，应该显式地创建和管理数据源：

var dataSource = new NpgsqlDataSourceBuilder(connectionString)
    .UseUsername("foo") // 或其他配置
    .Build();

services.AddDbContext<TestDbContext>(options => 
    options.UseNpgsql(dataSource));

3. 注意枚举映射和插件配置：当手动创建数据源时，需要确保在数据源和 EF Core 两个层面都正确配置了枚举映射和插件。

设计考量

这个问题反映了 ORM 框架设计中的一个常见挑战：如何在配置灵活性和性能优化之间取得平衡。EF Core 选择优先保证性能，通过缓存机制减少资源消耗，但这在某些特定场景下会限制配置的灵活性。

最佳实践建议

1. 对于生产环境应用，建议预先创建好所有需要的数据源实例。

2. 在开发过程中，如果发现配置没有按预期生效，首先检查是否是缓存机制导致的问题。

3. 考虑将数据库连接配置集中管理，而不是分散在各个服务配置中。

4. 对于需要动态配置的场景，可以结合使用配置中心和工厂模式来管理数据源。