领域驱动设计仓储模式下ODataQueryOptions合规集成方案咨询

核心解决方案 #

首先纠正你对[EnableQuery]特性的性能误区：只要你返回的是未被枚举的IQueryable对象，OData的过滤、排序、分页操作会被追加到表达式树中，最终由ORM（如EF Core）将所有操作翻译成SQL语句在数据库端执行，完全不会出现全量查询后再过滤的问题，你担心的10000条数据全量查询的场景根本不会发生。

在此基础上，只需要做一层DTO映射即可解决分层依赖问题，整套实现完全不破坏DDD分层规则： #

方案1：极简[EnableQuery]实现（推荐）

该方案无需下层任何修改，仅需在WebHost层做适配即可：

1. OData模型配置全部用DTO：OData的EDM模型仅配置Application.Contracts层中定义的PersonDto，完全不涉及Domain层的PersonEntity，WebHost层自然不需要引用Domain项目。
2. IQueryable延迟映射：从仓储拿到IQueryable<PersonEntity>后，直接用AutoMapper的ProjectTo方法转换成IQueryable<PersonDto>返回，全程不会触发查询。

示例代码：

// WebHost层OData配置，仅引用DTO
private static IEdmModel GetEdmModel()
{
    var builder = new ODataConventionModelBuilder();
    builder.EntitySet<PersonDto>("Persons");
    return builder.GetEdmModel();
}

// 控制器实现
[HttpGet("odata/persons")]
[EnableQuery]
public IQueryable<PersonDto> GetList()
{
    // 仓储返回未枚举的IQueryable<PersonEntity>，转成DTO的IQueryable后直接返回
    return _personRepository.GetAll()
        .ProjectTo<PersonDto>(_mapper.ConfigurationProvider);
}

该方案下，应用服务、仓储层完全感知不到OData的存在，WebHost层也不需要依赖Domain层的实体，完全符合分层规则。 #

方案2：OData参数转通用查询条件

如果需要更灵活的查询逻辑控制，可以将OData参数转换为通用的表达式参数传递到下层，全程不需要传递ODataQueryOptions对象：

1. WebHost层拿到ODataQueryOptions<PersonDto>后，用AutoMapper将针对DTO的过滤、排序表达式转换为针对PersonEntity的表达式。
2. 应用服务接口仅接收通用的过滤表达式、排序规则、分页参数，完全不依赖OData相关的类。

示例代码：

// Application.Contracts层的应用服务接口定义，无任何OData依赖
public interface IPersonAppService
{
    Task<List<PersonDto>> GetListAsync(
        Expression<Func<PersonEntity, bool>> filter = null,
        Func<IQueryable<PersonEntity>, IOrderedQueryable<PersonEntity>> orderBy = null,
        int? skip = null,
        int? take = null);
}

// WebHost层控制器实现
[HttpGet("persons")]
public async Task<List<PersonDto>> GetList([FromQuery] ODataQueryOptions<PersonDto> options)
{
    // 转换OData查询条件为针对实体的通用参数
    var filter = options.Filter?.ToExpression<PersonEntity>(_mapper.ConfigurationProvider);
    var orderBy = options.OrderBy?.ToSortFunc<PersonEntity>(_mapper.ConfigurationProvider);
    var skip = options.Skip?.Value;
    var take = options.Top?.Value;

    // 调用应用服务，下层完全不知道OData的存在
    return await _personAppService.GetListAsync(filter, orderBy, skip, take);
}

注意事项 #

不要在仓储层、应用服务层引入任何OData相关的依赖，所有OData的处理逻辑全部收敛在WebHost层，既不会出现跨层参数传递的问题，也不会破坏DDD的分层依赖规则。

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