У меня есть контроллер OData, который выглядит довольно стандартно.

 [HttpGet]
[ODataRoute("GridData")]
[EnableQuery]
public async Task<IQueryable<GridData>> GetGridData(ODataQueryOptions<GridData> odataOptions)
{
    var query = odataOptions.ApplyTo(_service.GetGridDataQueryable()) as IQueryable<GridData>
    return query;
}
  

Проекция выглядит следующим образом :

 .Select(async x =>
{
   //Pretty resource heavy
   x.Ownership = await _ownershipService.ComputeAsync(_currentUser)); 
   return x;
})
.Select(t => t.Result)
.ToList();
  

Теперь проблема в том, что мне нужно фактически вернуть объект GridDataDTO из этого вызова. Существует некоторая обработка, которая не может быть выполнена на уровне базы данных. Обработка довольно тяжелая, поэтому я бы не хотел добавлять ее в GetGridDataQueryable().Кроме того, обработка выполняется асинхронно, и для ее применения требуется материализованный набор результатов.

Мне также нужно вернуть IQueryable в контроллере, чтобы иметь возможность извлекать выгоду из $count, $ select и т.д.

Это подключается к довольно сложной сетке с множеством опций для фильтрации / сортировки, поэтому я бы не хотел удалять функциональность OData.

Есть ли простой способ добавить постобработку здесь? После того, как результат материализуется, спроецируйте его на мой GridDataDTO ?

Нет необходимости в поддержке вставки / обновления / удаления, поскольку это будет использоваться только для операций чтения.

Для вашего метода контроллера не требуется передавать только запрос из базы данных, фактически вашему методу вообще не нужно возвращать IQueryable<T> результат!

Вы все еще можете извлечь выгоду из OData $select , $expand и $filter операторов для наборов результатов, которые не являются IQueryable<T> , но вы теряете большую часть преимуществ в производительности от этого, и вам нужно подготовить данные, чтобы операторы могли быть обработаны, и вам придется явно украсить свою конечную точку [EnableQuery] атрибутом.

В следующем примере ваш текущий запрос материализуется в памяти, после применения параметров запроса мы можем выполнить итерацию по набору и манипулировать им по мере необходимости.
В конце возвращается тот же набор записей с измененными записями, приведенными как запрашиваемые для соответствия сигнатуре метода, однако метод все равно будет функционировать так же, если результат был IEnumerable<T>

Существует веский аргумент, который гласит, что вы должны вернуть IEnumerable<T> , потому что он передает правильную информацию о том, что набор записей был реализован и не отложен.

 [HttpGet]
[ODataRoute("GridData")]
public async Task<IQueryable<GridDataDTO>> GetGridData(ODataQueryOptions<GridData> odataOptions)
{
    // NOTE: GridDataDTO : GridData
    // apply $filter, $top and $skip to the DB query
    IQueryable<GridData> query = odataOptions.ApplyTo(_service.GetGridDataQueryable());
    // materialize
    var list = query.ToList();

    // project into DTO
    List<GridDataDTO> output = list.Select(async x =>
    {
        var o = new GridDataDTO(x);
        o.Ownership = await _ownershipService.ComputeAsync(_currentUser));
    }).ToList();
    
    // return, as Queryable
    return output.AsQueryable();
}
  

Обновить:

Когда манипуляции включают проекцию в новый тип, то для правильной поддержки параметров запроса OData тип, определенный в вашем, ODataQueryOptions<> должен быть присваиваемым из типа выходного элемента. Вы можете сделать это с помощью наследования или с помощью неявных определений приведения.

Если требуется явное приведение (или приведение вообще не доступно), вам придется вручную проверять ApplyTo логику, ODataQueryOptions должна быть допустимая ссылка на тип, чтобы соответствовать результату.