C# остановить асинхронное наследование

Я связываюсь со всей функциональностью async / await в C# прямо сейчас.

Думаю, я знаю, для чего это нужно. Но я сталкивался с местами, где я не хочу, чтобы общее наследование всех методов, вызывающих мою библиотечную функцию, было "асинхронным".

Подумайте об этом (грубый псевдокод, на самом деле не представляющий реальную вещь, это просто о контексте):

string JokeOfTheHour;

public string GiveJokeOfTheHour()
{
    if (HourIsOver)
    {
        jokeOfTheHour = thirdPartyLibrary.GetNewJoke().GetAwaiter().GetResult();
    }

    return jokeOfTheHour;
}
  1. У меня есть функция веб-библиотеки, которая вызывается до миллиона раз в час (или даже больше).
  2. Ровно один раз из этого миллиона вызовов в час внутренняя логика использует стороннюю библиотеку, которая просто поддерживает асинхронные вызовы для методов, которые я хочу использовать из нее.
  3. Я не хочу, чтобы пользователь моей библиотеки даже подумал, что для них имеет смысл асинхронно запускать любой код при вызове моей библиотечной функции, потому что это приведет только к ненужным накладным расходам для их кода, а во время выполнения - абсолютной большей части время.

Я бы назвал здесь следующие причины:

  1. Разделение озабоченности. Я знаю, как работаю, моему пользователю это не нужно.
  2. Контекст - это все. Как разработчик, имея базовые знания, я могу знать, какие случаи мне нужно учитывать при написании кода, а какие нет. Это позволяет мне не писать сотни строк кода для вещей, которые никогда не должны происходить.

Теперь я хочу знать, какие есть общие правила для этого. Но, к сожалению, я не могу найти простых утверждений или правил в Интернете, где кто-нибудь сказал бы: «В этой, этой и этой ситуации вы можете остановить это ключевое слово« async », всплывающее в вашем дереве вызовов методов». Я только что видел, как люди (некоторые из них Microsoft MVP) говорили о том, что существуют ситуации, в которых это должно быть сделано, а также заявляли, что вы должны использовать .GetAwaiter (). GetResult () в качестве лучшей практики, но они никогда не конкретно о самих ситуациях.

Я ищу простое общее правило, в котором я могу сказать:

Несмотря на то, что я могу вызывать сторонние функции, которые являются асинхронными, я не выполняю async и не хочу отображаться как таковые. Я работаю на нижнем уровне и использую кеши 99,99999% времени. Мне не нужно, чтобы мой пользователь реализовал методологию async полностью до того места, где моему фактическому пользователю нужно решить, где останавливается выполнение async (что заставляет моего пользователя, который действительно должен своевременно извлекать выгоду из моей библиотеки, писать больше кода и выполнять больше время).

Буду очень благодарен за вашу помощь :)

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

Ravior 21.08.2018 09:05

«Разделение озабоченности». - Тогда почему бы не довести его до максимума и разделить геттер и (асинхронный) апдейтер?

Fildor 21.08.2018 09:05

Спасибо за эту идею. Это действительно хорошо.

Ravior 21.08.2018 09:06

Я поддерживаю предложение @Fildor. И я также хочу упомянуть, что с вашей текущей структурой GetNewJoke будет вызываться более одного раза, если вы не используете механизм блокировки. А использование блокировки создает в вашем случае большое узкое место. Так что это еще одна причина, чтобы согласиться с предложением Филдора.

Nuri Tasdemir 21.08.2018 09:11

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

Damien_The_Unbeliever 21.08.2018 09:24

Пара статей Стивена Туба - часть 1 и часть 2

Damien_The_Unbeliever 21.08.2018 09:26
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
6
248
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Кажется, вы хотите, чтобы ваш метод представился словами: «Я быстр». Правда в том, что время от времени это может быть (очень) медленным. Это потенциально может иметь серьезные последствия.

Заявление

I'm a bottom level function using caches 99.99999% of the time'

неверно, если вы вызываете свой метод один раз в час.

Для потребителей вашего метода лучше видеть: «Я могу работать медленно, но если вы часто звоните мне, я кэширую результат, поэтому быстро вернусь» (это будет GiveJokeOfTheHourAsync() с комментарием).

Если вы хотите, чтобы ваш метод всегда был быстрым, я бы предложил один из следующих вариантов:

  • Имейте метод UpdateJokeAsync, который вы вызываете, не дожидаясь его в вашем if (HourIsOver). Это будет означать возврат устаревшего результата, пока вы не получите новый.
  • Обновите шутку с помощью таймера.
  • Сделайте так, чтобы "получить" всегда получал последнее известное, и используйте UpdateJokeAsync, чтобы обновить анекдот.

Другие вопросы по теме