Elasticsearch .NET客户端Source过滤查询返回DTO的自定义字段映射方法

NEST的序列化机制原生支持在DTO属性层面，通过显式特性绑定对应索引的实际字段名。查询构造阶段完全基于索引POCOFooIndex做字段引用与逻辑编写，不需要为DTO的自定义属性修改原有查询代码，仅需在结果反序列化环节完成字段匹配。

具体改造步骤 #

1. 引入NEST提供的PropertyName特性，给需要映射的自定义属性指定对应的ES实际字段名，改造后的DTO代码如下：

using Nest;

public class FooStatus
{
    public string FooId { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    // 映射索引中PrimaryEmail对应的实际字段
    [PropertyName("primaryEmail")]
    public string Email { get; set; }
    // 映射索引中UpdatedDate对应的实际字段
    [PropertyName("updatedDate")]
    public DateTime? DateModified { get; set; }
    public List<FooStatus> Statuses { get; set; }
}

2. 原有构造查询的代码完全不需要调整：
   • Source.Includes部分基于FooIndexPOCO筛选返回字段的逻辑会正常生效，确保需要映射的PrimaryEmail、UpdatedDate等字段被包含在返回的_source范围内
   • 针对Statuses.blahId的Terms过滤查询逻辑不受DTO属性命名的影响，依然会按照FooIndex的映射规则构造正确的查询语句

关键注意点 #

• PropertyName特性声明的字段名，需要和Elasticsearch索引中实际存储的字段名大小写完全一致；如果全局配置过自定义的字段名转换规则（比如把PascalCase转成下划线命名），要以ES中真实存储的字段名为准，特性的优先级高于全局的字段名推断规则
• 没有添加PropertyName特性的DTO属性，依然会按照NEST默认的字段名推断规则匹配结果字段，和现有已正常运行的逻辑完全兼容，不需要额外调整
• 嵌套的复杂对象（比如Statuses）如果存在自定义属性名，同样可以在嵌套对象的类属性上添加PropertyName特性完成映射，不需要修改查询逻辑
• 不需要在SearchDescriptor中提前声明DTO的映射关系，因为字段映射是在ES返回结果的反序列化阶段生效，和查询构造流程完全解耦

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