Как отложить выполнение запроса EF до тех пор, пока он действительно не понадобится

var userRoles;

if (unrelatedConditions == 1) { doSomething1(); }
else if (unrelatedConditions == 2) { doSomething2(); }
else if (unrelatedConditions == 3) { doSomething3(); }
else {
    userRoles = await DAL.GetUserRolesAsync(userId); // Expensive query using EF
    if (userRoles.Any(x => x.role == "red")) { logicForRedRole(); }
    else if (userRoles.Any(x => x.role == "blue")) { logicForBlueRole(); }
    else if { ... }
}

Вы можете реализовать и объявить его как IQueryable. Когда вам это понадобится, вы можете вызвать метод ToList() в этой функции. Таким образом, он будет выполнен после вызова метода ToList().

Как насчет извлечения метода:

if (unrelatedConditions == 1) { doSomething1(); }
else if (unrelatedConditions == 2) { doSomething2(); }
else if (unrelatedConditions == 3) { doSomething3(); }
else if ( await IsUserRole() )
else if ...

//...

private async Task<bool> IsUserRole()
{
    var userRoles = await DAL.GetUserRolesAsync(userId); // Expensive query using EF

    if (userRoles.Any(x => x.role == "red")) 
    {
        logicForRedRole(); 
        return true;
    }
    if (userRoles.Any(x => x.role == "blue")) 
    {
        logicForBlueRole(); 
        return true;
    }
    return false;
}

И еще одна возможность — использовать Lazy<T>:

using System;
using System.Linq;
using System.Collections.Generic;
using System.Threading.Tasks;
                    
public class Program
{
    public static async Task Main()
    {
        // Just for example ...
        bool condition(int conditionNr) {
            Console.WriteLine("Testing condition #{0}", conditionNr);
            return false;
        }
        
        // The expensive Query
        var userId = 5;
        var expensiveDbAccess = new Lazy<Task<IEnumerable<int>>>(async () => {
            Console.WriteLine("Executing expensive query for User '{0}'", userId);
            await Task.Delay(1000); // "Doing some work"
            return new List<int>{1,2,3,4,5};
// This body would actually just be your
// return await DAL.GetUserRolesAsync(userId);
        });
        
        Console.WriteLine("Going down the rabbit hole ...");
        
        if (condition(1)){ Console.WriteLine("1"); }
        else if (condition(2)){ Console.WriteLine("2"); }
        else if (condition(3)){ Console.WriteLine("3"); }
        else if ( (await expensiveDbAccess.Value).Contains(6) ){ Console.WriteLine("Contained 6"); }
        else if ( (await expensiveDbAccess.Value).Contains(3) ){ Console.WriteLine("Contained 3"); }
        else if (condition(4)){ Console.WriteLine("4"); }
        else if (condition(5)){ Console.WriteLine("5"); }
    }
}

Я проверил это в Fiddle.

Выход:

Going down the rabbit hole ...
Testing condition #1
Testing condition #2
Testing condition #3
Executing expensive query for User '5'
Contained 3

Если вам нужен более сложный пример, не стесняйтесь комментировать или дополнять свой вопрос.

Если вы хотите получить какую-то «ленивую» загрузку, вы можете сделать следующее:

    public async Task YourMethod(Guid userId)
    {
        if (unrelatedConditions == 1) { doSomething1(); }
        else if (unrelatedConditions == 2) { doSomething2(); }
        else if (unrelatedConditions == 3) { doSomething3(); }
        else if ((await GetRolesAsync(userId)).Any(x => x.role == "red")) { logicForRedRole(); }
        else if ((await GetRolesAsync(userId)).Any(x => x.role == "blue")) { logicForBlueRole(); }
    }

    private List<Role> _roles;
    private async ValueTask<List<Role>> GetRolesAsync(Guild userId)
    {
        return _roles ??= await DAL.GetUserRolesAsync(userId)
    }

Обратите внимание: если ваша версия фреймворка не поддерживает ValueTask, вы можете заменить его на Task

Как указано в моем комментарии к ответу Филдора, в итоге я выбрал совершенно другой маршрут и смог полностью реорганизовать дорогостоящий запрос на более мелкие части, каждая из которых выполняется только тогда, когда они действительно необходимы.

Но я все еще был заинтересован в решении проблемы на будущее, и, вдохновившись ответом Ярослава, я смог за выходные придумать что-то, что почти идеально удовлетворяет тому, что я искал. Это действительно простая универсальная функция, которую вы можете просто добавить в служебный класс для удобства использования. Вот код:

public static Func<Task<T>> CreateLazyTask<T>(Func<Task<T>> asyncCall)
{
    Task<T> executedTask = null;
    return () => executedTask ??= asyncCall();
}

Используя мой первоначальный пример кода, это можно использовать так:

var userRolesTask = CreateLazyTask(() => DAL.GetUserRolesAsync(userId)); // Expensive query using EF

if (unrelatedConditions == 1) { doSomething1(); }
else if (unrelatedConditions == 2) { doSomething2(); }
else if (unrelatedConditions == 3) { doSomething3(); }
else if ((await userRolesTask()).Any(x => x.role == "red")) { logicForRedRole(); }
else if ((await userRolesTask()).Any(x => x.role == "blue")) { logicForBlueRole(); }
// more else if blocks...

Есть несколько вещей, на которые стоит обратить внимание в этой реализации. Прежде всего, это то, что не используется async/await, и он просто возвращает Task<T> из asyncCall, поэтому он не пытается создать конечный автомат или что-то еще для этого, и ему не придется перепаковывать результаты в завершенный Task<T> в последующем. вызовов (это то, что делает код Ярослава), есть только один Task<T>, созданный asyncCall, который возвращается для каждого вызова функции, возвращаемой CreateLazyTask (что похоже на код Fildor Lazy<T>).

Кроме того, я почти уверен, что это должно быть потокобезопасным (в традиционном смысле). Таким образом, должна быть возможность создать функцию с этим и передать ее в набор рабочих потоков, и она будет выполнена в первый раз, когда она потребуется, и если другие потоки ожидают ее до завершения, она просто обработает ее правильно и возобновит все потоки, когда задача завершится, и последующие вызовы просто получат результат напрямую и продолжат работу. Я не думаю, что метод Ярослава будет потокобезопасным (я думаю, что одновременные вызовы вызовут многократное выполнение запроса, пока не будет возвращен результат), и я не совсем уверен, как пример Lazy<T> поведет себя в этом сценарии.

-- Если подумать об этом немного подробнее, на самом деле может быть очень небольшой временной отрезок, когда несколько вызовов могут инициировать выполнение несколько раз (между моментом выполнения asyncCall и срабатыванием первого ожидания, чтобы он мог назначить Task<T> обратно на executedTask), но обычно это будет гораздо меньшее окно, чем ожидание его фактического завершения. Существует также множество других сложностей, связанных с тем, какой тип данных возвращается и как они будут использоваться, которые необходимо учитывать, прежде чем фактически использовать что-то подобное в сценарии, допускающем параллельное выполнение. ---

Далее, нет необходимости указывать тип возвращаемого значения, так как компилятор может определить это непосредственно из переданного в asyncCall. Кроме того, нет необходимости использовать await для чего-то другого, кроме того, что создается (например, свойство Value в примере Lazy<T>), он просто ожидает результатов созданной функции. Так это намного легче читается.

Так что это в основном лучшие части ответов Филдора и Ярослава, все они заключены в очень аккуратно содержащуюся общую функцию, которую можно использовать где угодно для любого типа асинхронного вызова. Я надеюсь, что это поможет всем, у кого были такие же трудности, как и у меня! 😁

--- Изменить в ответ на комментарий о безопасности потоков ---

Итак, Стивен Клири, по-видимому, написал статью о создании асинхронной версии Lazy<T> под названием AsyncLazy<T> . Там он заявил, что «он не будет выполняться более одного раза, даже если несколько потоков попытаются запустить его одновременно (это гарантируется ленивым типом)». Так как он сказал это, я считаю, что метод Lazy<T> будет потокобезопасным. (Хотя глядя на справочный источник для Lazy<T>, я вижу комментарии, которые заставляют меня думать, что это все еще не 100% ...) В этой статье есть некоторые другие странности, которые я не понимаю (например, его использование Task. Run, который он специально не рекомендует во многих других статьях), но в целом это довольно хорошо, и похоже, что с тех пор он немного изменил его в своем проекте AsyncEx (включая удаление Task.Run).

Но для тех, кому нужно использовать то, что я написал, там, где требуется потокобезопасность, вот версия, которая использует Lazy<T> для предотвращения условий гонки:

public static Func<Task<T>> CreateLazyTask<T>(Func<Task<T>> asyncCall)
{
    var lazy = new Lazy<Task<T>>(asyncCall);
    return () => lazy.Value;
}