关于.NET Standard 2.0无DbGeography时ASP.NET Core v2空间计算的替代方案问询

嘿，我完全懂你在ASP.NET Core 2.x Web API里搞空间计算时遇到的麻烦——DbGeography确实没被.NET Standard 2.0支持，这事儿确实挺闹心的。不过不用慌，目前有几个靠谱的替代方案，我给你逐一拆解：

1. 用NetTopologySuite（NTS）——最推荐的方案 #

这是.NET生态里最成熟、功能最全面的空间处理库，完全兼容.NET Standard 2.0，不管是基础的坐标处理还是复杂的空间关系计算（比如相交、包含、距离测算）都能搞定，甚至比DbGeography的功能还丰富。

如果你用EF Core 2.x做数据持久化，还能通过NetTopologySuite.EntityFrameworkCore包把NTS的空间类型直接映射到数据库的空间字段（比如SQL Server的geography或geometry类型）。举个简单的实现例子：

首先定义实体类：

using NetTopologySuite.Geometries;

public class StoreLocation
{
    public int Id { get; set; }
    public string StoreName { get; set; }
    // 用NTS的Point类型存储坐标
    public Point Coordinates { get; set; }
}

然后在DbContext里配置空间字段映射：

using NetTopologySuite.EntityFrameworkCore;

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<StoreLocation>()
        .Property(s => s.Coordinates)
        .HasColumnType("geography"); // 对应SQL Server的geography类型
}

在Web API里处理序列化的话，还可以用NetTopologySuite.IO.GeoJSON包，把NTS的空间类型直接序列化为前端友好的GeoJSON格式，不用自己手动转换。

2. 手动处理WKT/WKB格式——适合简单场景 #

如果你的空间计算需求比较简单，不想引入第三方库，也可以直接用**Well-Known Text（WKT）或Well-Known Binary（WKB）**来传递和处理空间数据。

比如在API接口里接收字符串类型的WKT（例如"POINT(-122.3331 47.6097)"），然后自己解析出经纬度进行计算；计算完成后再把结果转换成WKT格式返回给前端。不过这种方式需要你自己实现基础的空间计算逻辑，复杂场景下会比较繁琐，所以只推荐给需求简单的项目。

3. 升级.NET版本（如果项目允许） #

如果你的项目没有严格的版本约束，升级到.NET Core 3.0及以上会是一劳永逸的方案——.NET Standard 2.1开始原生支持更多空间相关的API，而且EF Core 3.x+也内置了对空间数据的支持，不用再依赖第三方库。不过如果因为项目历史原因没法升级，前面两个方案会更适合你。

内容的提问来源于stack exchange，提问作者Paul Stanley