在.NET 5.0中结合OData使用AutoMapper Queryable扩展的嵌套$select问题

我之前也碰到过一模一样的问题，这个冲突本质是AutoMapper的ProjectTo生成的表达式和OData查询的表达式树在类型转换上的矛盾——尤其是当实体属性和DTO属性的可空性不一致时（比如实体里的Category是非可空值类型，DTO里定义成了可空的Nullable<Category>），EF Core的查询优化器会阻止这种可能改变语义的类型重写，从而抛出你看到的异常。

下面给你几个经过验证的可行解决方案：

方案1：对齐DTO与实体的属性可空性 #

先检查你的数据库实体（比如Press）和PressDto里Category属性的可空性：

• 如果实体的Category是非可空的（比如public Category Category { get; set; }），那把DTO里的Category也改成非可空的public Category Category { get; set; }
• 如果实体的Category本身就是可空的，那保持DTO的Nullable<Category>即可

这样ProjectTo生成的表达式不会有多余的类型转换操作，OData的$select就能正常解析了。

方案2：显式配置AutoMapper的类型转换 #

如果业务需求必须让DTO的Category保持可空（比如前端需要接收可空值），可以在AutoMapper的映射配置里显式处理这个类型转换，提前规避EF Core的表达式树检查：

// 在AutoMapper Profile配置中
CreateMap<Press, PressDto>()
    .ForMember(dest => dest.Category, opt => 
        opt.MapFrom(src => (Category?)src.Category));

这种显式的类型转换会让ProjectTo生成的表达式提前处理可空转换逻辑，OData查询时就不会触发那个类型重写的异常了。

方案3：调整查询顺序，先应用OData查询再映射 #

既然你已经在手动检查展开语句，也可以换个思路：先对数据库实体应用OData查询，再映射到DTO，绕过ProjectTo和OData表达式的冲突：

[EnableQuery]
public IActionResult Get(ODataQueryOptions<Book> options) {
    // 先对实体应用OData的查询规则
    var entityQuery = options.ApplyTo(this._db.Books) as IQueryable<Book>;
    // 再将查询结果映射到DTO
    var books = entityQuery.ProjectTo<BookDto>(_mapper.ConfigurationProvider);
    return Ok(books);
}

注意这里要把ODataQueryOptions的泛型参数改成实体类型Book，同时要确保实体和DTO的导航属性结构完全一致，避免OData查询和映射逻辑不匹配的问题。

方案4：手动指定EDM模型的属性可空性 #

有时候OData的ODataConventionModelBuilder会对DTO属性的可空性推断错误，导致EDM模型的元数据和实际类型不匹配，也会触发这个异常。可以手动指定EDM属性的可空性：

ODataConventionModelBuilder builder = new ODataConventionModelBuilder();
// 显式配置PressDto的Category属性可空性
var pressEntity = builder.EntityType<PressDto>();
pressEntity.Property(p => p.Category).IsNullable(false); // 或者true，根据你的实际类型调整
builder.EntitySet<PressDto>("Presses");
builder.EntitySet<BookDto>("Books");
return builder.GetEdmModel();

让EDM模型的属性可空性和DTO、实体的实际类型保持一致，减少OData查询时的表达式转换冲突。

补充说明 #

这个问题的核心是EF Core的查询优化器对表达式树的严格检查——它不允许无意义的类型重写（比如把非可空值类型强制转成可空），而ProjectTo和OData的$select结合时，很容易生成这种触发检查的表达式。上面的四个方案分别从类型匹配、显式转换、查询顺序、EDM配置四个角度解决了这个冲突，你可以根据自己的业务场景选择最合适的一种。

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