使用LINQ+DBGeography实现附近地点查询时Where条件报错问题

问题背景 #

要在服务器端完成地理距离计算，实现移动应用的附近地点查询，通过LINQ结合DbGeography.PointFromText编写查询后，对计算出的distance添加过滤条件时，EF Core无法将LINQ表达式翻译成SQL，报错提示表达式无法翻译。原查询使用嵌套子查询和自连接，结构复杂导致翻译失败，需求仅为获取地点ID及对应距离。

解决方案 #

重构查询结构，移除不必要的自连接，直接在主查询中关联ApplicationInstance和Addresses表，使用let关键字定义地理点与距离变量，确保EF Core能正确解析并转换为数据库原生地理函数。

优化后的查询代码

// 提前构建用户位置的DbGeography对象，避免重复生成
var userGeoPoint = DbGeography.PointFromText($"POINT({locationVM.Longitude} {locationVM.Latitude})", 4326);
// 转换距离单位（假设输入为千米，转为米）
var maxAllowedDistance = locationVM.Distance * 1000;

// 直接关联表并完成距离计算与过滤
var nearbyLocations = await (from instance in _applicationDbContext.ApplicationInstances
                            join address in _applicationDbContext.Addresses 
                                on instance.AddressId equals address.AddressId
                            // 过滤未删除的数据
                            where !instance.IsDeleted && !address.IsDeleted
                            // 构建地址对应的地理点
                            let addressGeoPoint = DbGeography.PointFromText($"POINT({address.Longitude} {address.Latitude})", 4326)
                            // 计算当前地址与用户位置的距离
                            let distance = addressGeoPoint.Distance(userGeoPoint)
                            // 筛选距离范围内的地点
                            where distance <= maxAllowedDistance
                            // 返回需求的ID和距离
                            select new 
                            {
                                instance.ApplicationInstanceId,
                                Distance = distance
                            }).ToListAsync();

关键说明 #

1. 简化查询结构：原查询的自连接完全冗余，直接关联ApplicationInstance和Addresses即可获取地址信息，降低EF Core的翻译复杂度。
2. 复用用户位置对象：提前生成用户位置的DbGeography实例，避免在查询中重复调用PointFromText，提升性能同时简化表达式。
3. 使用let关键字：通过let定义临时变量存储地理点和距离，EF Core能更好地识别这类表达式，并翻译成对应的数据库地理函数（如SQL Server的STDistance）。
4. 依赖数据库支持：需确保数据库支持地理类型（如SQL Server的geography类型），且使用对应EF Core提供程序（如Microsoft.EntityFrameworkCore.SqlServer），这类提供程序内置了地理函数的翻译逻辑。

内容的提问来源于stack exchange，提问作者Ajay Kumar