Член C#, чтобы проверить свойство на нулевое значение и при необходимости установить его с помощью асинхронной функции?

Я думаю, ты был почти там с

private async Task<bool> IsUserSet()
{
     if (null != user)
         return await Task.FromResult<bool>(user);
     
     return await getUserAsync();
}

но return await Task.FromResult<bool>(user); должно быть return true;

Вы можете упростить это и сделать что-то похожее на исходный код.

private async Task<bool> IsUserSet()
{
     return user is not null || await getUserAsync();
}

Примечание на странице await Task.FromResult()

Когда вы это сделаете await Task.FromResult<bool>(user), у вас будет лишний код.

Task.FromResult<bool>(user) оборачивает user в завершенную задачу и префикс await автоматически разворачивает ее, поэтому await Task.FromResult<bool>(user) можно сократить до user, поскольку на самом деле вы не возвращали Task<bool>, но bool все время и помечаете метод как async автоматически оборачивает возвращаемое значение в задачу`

Я бы дал читабельный ответ - в конце концов, код, написанный так, чтобы его было легко понять, является самым элегантным из всех :)

private async Task<bool> IsUserSet()
{
    if (user == null)
    {
        return false;
    }
    else
    {
        return await getUserAsync();
    }
}

Говоря об этом, я бы, вероятно, прокомментировал выбор имени для getUserAsync(), поскольку на самом деле он не возвращает пользователя. Правильный выбор имени сделал бы код более читабельным.

Перейдем к сути вопроса:

Тем не менее, мне интересно, стоит ли снижение производительности (есть один с вставкой другой задачи, не так ли?) или есть способ сделать это без вставки другой задачи. (Или, может быть, мне просто нужно немного узнать, как писать более чистый код ASP.NET!)

Общая рекомендация — использовать Task, если только вы не столкнулись со сценарием, критичным к производительности, где его использование становится (или может стать) проблемой. Да, с Tasks есть небольшие накладные расходы, но это .NET, практически со всем есть некоторые накладные расходы. Если вы пишете базовую структуру или библиотеку, ориентированную на производительность, то обязательно подумайте об этих темах, но в этих проектах обычно уже есть некоторые рекомендации о том, где и как важна производительность.

Чтобы объяснить немного дальше, по сути, Task выделения состоят из двух частей:

• Сам объект Task
• Асинхронный конечный автомат, представляющий метод async в случае, когда await действительно вызывает приостановку.

В некоторых случаях выделения объекта Task можно избежать. При синхронном возврате Task существует синглтон Task.CompletedTask, который можно использовать повторно. Однако существует также кэширование для определенных сценариев, таких как Task<bool> — синхронно завершенный Task<bool> может содержать либо true, либо false, поэтому среда выполнения кэширует два экземпляра. Поскольку рассматриваемый сценарий работает с Task<bool>, синхронный путь по существу не требует выделения ресурсов, и это не является проблемой.

Асинхронный конечный автомат выделяется в случае приостановки. Это когда метод не завершается синхронно (т. е. потому, что выполняется фактический ввод-вывод, например отправка HTTP-запроса). Среде выполнения необходимо хранить локальные значения и продолжение в куче, чтобы она могла продолжить работу в том же логическом контексте после завершения асинхронной операции. Таким образом, в этом случае распределения не избежать.

Некоторые распределения конечных автоматов можно исключить, не используя асинхронные методы, когда await не требуется, например.

// Before: async
public async Task DoWorkAsync()
{
    DoSomething();
    DoSomethingElse();
    await DoSomethingAsync();
}

// After: no async, return task from callee
public Task DoWorkAsync()
{
    DoSomething();
    DoSomethingElse();
    return DoSomethingAsync();
}

Однако это приводит к тому, что эти методы больше не присутствуют в трассировках стека, и это не следует недооценивать.

Также существует понятие ValueTask и ValueTask<T>. Это структуры, поэтому их создание не распределяется. Тем не менее, они по-прежнему выделяют блок конечного автомата при приостановке асинхронного метода, и он немного больше, чем тот, который был создан для Task. Есть случай, когда этого также можно избежать с помощью ValueTask, который использует IValueTaskSource для объединения хранилища асинхронного состояния. Это действительно сложно и применимо не везде.

Итак, подведем итог:

*) Есть и другие исключения, такие как int в диапазоне [-1, 9), null, default(T) для некоторых типов значений.

**) Если не используется IValueTaskSource, который не распространен в коде приложения.

Несколько лет назад Стивен Тауб написал сообщение в блоге , в котором подробно раскрывается эта тема и служит прекрасным обзором. Я также могу порекомендовать блог Стивена Клири, где он объясняет темы, связанные с async/await и многое другое.

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

private async Task<bool> IsUserSetAsync()
{
    return user != null || await getUserAsync();
}

или, если вам действительно необходимо исключить ожидание:

private Task<bool> IsUserSetAsync()
{
    if (user != null)
    {
        return Task.FromResult(true);
    }
    else
    {
        return getUserAsync();
    }
}