C#使用ABP+Blazor+MongoDB时GUID搜索异常问题排查

问题背景 #

在Blazor项目中结合ABP框架使用MongoDB作为数据库，已完成数据库对象的列表展示功能，但在通过GUID值检索对应数据库对象时遇到异常。
前端调用检索的任务方法代码如下：

private async Task GetObjectAsync(string filter)
{
    var result = await ObjectAppService.GetListAsync(
        new GetObjectListDto
        {
            MaxResultCount = PageSize,
            SkipCount = CurrentPage * PageSize,
            Sorting = CurrentSorting,
            Filter = filter
        }
    );
    ObjectList = result.Items;
    TotalCount = (int)result.TotalCount;
    errorVal = TotalCount.ToString();
}

应用服务层GetListAsync方法初始代码如下：

public async Task<PagedResultDto<ObjectDto>> GetListAsync(GetObjectListDto input)
{
    if (input.Sorting.IsNullOrWhiteSpace())
    {
        input.Sorting = nameof(Object.Payload);
    }

    var objects = await _objectRepository.GetListAsync(
        input.SkipCount,
        input.MaxResultCount,
        input.Sorting,
        input.Filter
    );

    var totalCount = input.Filter == null
        ? await _objectRepository.CountAsync()
        : await _objectRepository.CountAsync(
            // 检索逻辑待填充
        );

    return new PagedResultDto<ObjectDto>(
        totalCount,
        ObjectMapper.Map<List<Object>, List<ObjectDto>>(objects)
    );
}

已尝试的检索方案 #

开发过程中先后测试了三种过滤逻辑：

• 按名称模糊匹配：object => object.Name.Contains(input.Filter)
  该方案运行完全正常，可以按名称关键字返回匹配结果，但无法支持GUID检索需求。
• 按ID转字符串后模糊匹配：object => object.Id.ToString().Contains(input.Filter)
  该方案最符合预期使用效果，但运行时抛出异常：System.ArgumentException: Unsupported filter: {document}{_id}.ToString().Contains("70f35018-a504-89f1-51c0-3a04cb49cb97")
• 按ID全等匹配：object => object.Id.Equals(Guid.Parse(input.Filter))
  该方案可以正确检索到匹配数据，Equals本身是全等匹配逻辑，天然要求输入值和存储值完全一致才能命中，因此必须输入完整合法GUID才能返回结果，使用体验较差；同时因前期仓储层过滤字段绑定错误，偶现匹配结果无法在页面展示的问题。

初步排查进展 #

排查Mongo仓储层代码后定位到第一个问题：之前的过滤逻辑错误绑定了Payload属性而非Id属性，修正后的仓储层查询代码如下：

public async Task<List<Object>> GetListAsync(
    int skipCount,
    int maxResultCount,
    string sorting,
    string filter = null)
{
    var queryable = await GetMongoQueryableAsync();
    return await queryable
        .WhereIf<Object, IMongoQueryable<Object>>(
            !filter.IsNullOrWhiteSpace(),
            obj => obj.Id.Equals(filter)
        )
        .OrderBy(sorting)
        .As<IMongoQueryable<Object>>()
        .Skip(skipCount)
        .Take(maxResultCount)
        .ToListAsync();
}

修正后全等匹配逻辑可以正常工作，但仍存在两个待解决的疑问：

1. 为什么obj => obj.Id.ToString().Contains(filter)这类写法无法正常运行？在DateTimeOffset类型字段上使用ToString().Contains()写法也会抛出同类异常，是否是数据库查询本身不支持这类写法？
2. 在WhereIf方法后追加.FirstOrDefault()会导致查询函数失效，必须保持链式调用才能正常运行，是否是该问题的诱因？

问题解答 #

1. ToString().Contains()写法运行异常的原因 #

MongoDB官方提供的LINQ查询提供程序，无法将C#中针对非字符串类型的ToString()方法调用翻译为MongoDB可识别的原生查询语法。这类方法调用属于内存执行逻辑，在翻译成数据库查询管道的阶段就会被判定为不支持的操作，直接抛出参数异常。
不止是GUID类型的主键字段，DateTimeOffset、数值、布尔等非字符串存储类型，直接调用ToString()后做Contains模糊匹配都会触发同类错误——MongoDB本身没有针对这些原始类型的「存储值转字符串后做子串匹配」的内置查询逻辑，驱动无法自动完成这类逻辑的翻译。
要实现GUID的模糊搜索，可参考两种落地方式：

• 持久化冗余字段：在实体定义中额外增加一个字符串类型的IdStr字段，数据新增、更新时自动将GUID主键转为字符串赋值给该字段，后续模糊查询直接针对IdStr字段做Contains匹配即可，兼容性和查询性能最优，是生产环境的推荐方案。
• 内存过滤：先执行无过滤的数据库查询把分页范围内的数据拉到应用内存中，再在内存里执行ToString().Contains()过滤，该方案在数据量稍大时会产生明显的性能损耗，仅适合数据规模极小的内部场景使用。

2. WhereIf后追加FirstOrDefault()失效的原因 #

定义的仓储GetListAsync方法返回值类型是List<Object>，而FirstOrDefault()执行后返回的是单个Object实体（无匹配时返回null），返回值类型和方法签名的约定完全不匹配，自然会导致函数运行/编译失败，和之前的过滤逻辑异常没有关联。
如果需要查询单条匹配数据，应该单独定义返回单个实体的仓储方法，不要在分页列表的查询链式逻辑中追加FirstOrDefault()这类会改变返回结果结构的方法。

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