Блог

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

Мы абстрагировали интерфейс System.Net.SmtpClient behind an, чтобы мы могли легко тестировать код, который отправляет электронные письма.

Поскольку SmtpClient на самом деле имеет как асинхронную, так и синхронную реализации, должны ли мы предоставлять обе из них или просто ожидать, что любой потребитель нашего ISmtpClient интерфейса будет использовать только Wait наш асинхронный SendAsync метод.

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

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

Вы можете увидеть много примеров этого в .Net библиотеках, таких как SemaphoreSlim ( Wait/WaitAsync ) или TPL Dataflow ( Post/SendAsync ) . Почти всегда, когда есть опция async, есть также опция синхронизации. Единственный случай, который я могу вспомнить, когда есть только асинхронная версия WinRT , но это потому, что они препятствуют длительным вызовам синхронизации.

Как упоминал Нед Стоянов, статья Тоуба больше посвящена оболочкам, а не истинным операциям синхронизации / асинхронности.

Я думаю, что в статье больше говорится о случае, когда ваш API предоставляет только async реализации, в этом случае клиенту так же легко предоставить реализацию «синхронизация по асинхронности», поэтому вы не добавляете никакого значения, предоставляя ее. Я думаю, что в случае, когда предоставлены оба, вы должны предоставить оба.