Npgsql 8.0 中NodaTime与NetTopologySuite扩展的配置问题解析

背景介绍

在Npgsql 8.0版本中，许多开发者遇到了一个常见问题：当使用依赖注入方式配置DbContext时，NodaTime和NetTopologySuite扩展无法正常工作。这个问题特别出现在从Npgsql 7.0升级到8.0的过程中，许多开发者发现他们原有的配置方式不再适用。

问题现象

开发者在使用Npgsql 8.0时，尝试通过以下方式配置DbContext：

services.AddNpgsql<ApplicationContext>(configuration.GetConnectionString("RouteDb"), x =>
{
    x.UseNodaTime();
    x.UseNetTopologySuite();
    x.MigrationsHistoryTable("__EFMigrationsHistory", "public");
    x.MigrationsAssembly("Migrations");
});

然而，这种配置方式会导致NodaTime和NetTopologySuite扩展无法正常工作，系统会抛出"NpgsqlDbType 'Geometry'"相关的异常，表明这些类型无法被正确处理。

问题根源

这个问题的根本原因在于Npgsql 8.0推荐使用NpgsqlDataSourceBuilder来构建数据源，而不是直接使用连接字符串。在Npgsql 7.0中，开发者通常会同时配置两个层级：

1. 在NpgsqlDataSourceBuilder层级配置类型映射
2. 在EF Core层级再次配置相同的类型映射

而在Npgsql 8.0中，如果只配置EF Core层级而不配置Npgsql底层，就会导致类型映射失败。

解决方案

推荐方案：使用NpgsqlDataSourceBuilder

目前推荐的解决方案是继续使用NpgsqlDataSourceBuilder来显式构建数据源：

var appDsRaw = new NpgsqlDataSourceBuilder(configuration.GetConnectionString("RouteDb"));
appDsRaw.UseNodaTime();
appDsRaw.UseNetTopologySuite();
var appDs = appDsRaw.Build();

services.AddDbContext<ApplicationContext>(options => options.UseNpgsql(appDs,
    x =>
    {
        x.UseNodaTime();
        x.UseNetTopologySuite();
        x.MigrationsHistoryTable("__EFMigrationsHistory", "public");
        x.MigrationsAssembly("Migrations");
    })
);

这种方式虽然需要编写更多代码，但它是目前最可靠的方法。

替代方案：全局类型映射

如果不使用NpgsqlDataSourceBuilder，可以考虑使用全局类型映射：

NpgsqlConnection.GlobalTypeMapper.UseNodaTime();
NpgsqlConnection.GlobalTypeMapper.UseNetTopologySuite();

services.AddNpgsql<ApplicationContext>(configuration.GetConnectionString("RouteDb"), x =>
{
    x.UseNodaTime();
    x.UseNetTopologySuite();
    // 其他配置...
});

未来改进方向

Npgsql团队已经意识到当前的双重配置方式不够理想，正在考虑以下改进方案：

1. 让EF Core层级的配置自动应用到Npgsql底层，避免重复配置
2. 提供更简洁的API来同时配置两个层级

这些改进将简化配置流程，减少开发者出错的可能性。

最佳实践建议

1. 优先使用NpgsqlDataSourceBuilder方式配置数据源
2. 确保在两个层级都正确配置了类型映射
3. 密切关注Npgsql的更新，未来版本可能会提供更简洁的配置方式
4. 在升级版本时，仔细检查类型映射相关的配置

通过遵循这些建议，开发者可以确保NodaTime和NetTopologySuite扩展在Npgsql 8.0中正常工作，避免类型映射相关的问题。