Внедрение методов HttpWebRequest Async

Question

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

Мне известно о async/await, а также об изменениях в .NET 4.5, но в настоящее время мы используем .NET 4.0. Я также знаю о Microsoft.Bsl.Async и по другим причинам, который в настоящее время не является вариантом.

Я использую код примера от This Article on Async with HttpWebRequest в качестве ссылки.

Вопрос, который у меня есть, заключается в том, что если я не обновляю пользовательский интерфейс или не делаю других вещей между BeginXXXX и EndXXXX, но время исходящих вызовов ввода-вывода составляет 40 + секунд каждый, стоит ли реализовать этот асинхронный, или я должен придерживаться синхронного исполнения?

Answer 1

Я бы сказал, что это определенно стоит того. Это субъективный суждение, особенно на стороне сервера, но 40 секунд довольно значительны. Предполагая, что ваша служба не привязана к ЦП, я бы сказал, что около 0,5 секунды достаточно быстро, и вы решили сделать ее синхронной. В течение 40 секунд, безусловно, идет асинхронно.

Если вы используете ASP.NET с .NET 4.0, вы не можете использовать Microsoft.Bcl.Async. Однако, если ваша служба - это что-то другое (например, служба Win32), вы можете использовать Microsoft.Bcl.Async. В любом случае, планируйте обновление до .NET 4.5, когда сможете. Вы собираетесь узнать, как сильно болит async.

Что касается вашей структуры кода, я рекомендовал бы один из двух подходов:

1. Используйте Event-based Asynchronous Pattern (EAP).
2. Использование Task обертки вокруг Asynchronous Programming Model (APM) API.

Подход EAP является более чистым. С EAP вы должны использовать WebClient вместо HttpRequest. Например, вызовите метод DownloadStringAsync и обработайте событие DownloadStringCompleted. Преимущества этого в том, что EAP будет уведомлять ваш текущий контекст о том, что выполняется асинхронная операция, уведомить его снова, когда операция завершена, и использовать этот контекст для выполнения обработчика событий. Это особенно важно, если вы размещены в ASP.NET.

Недостаток шаблона EAP заключается в том, что он всегда использует контекст (даже если он вам не нужен).

Task Подход APM-обертки - это немного больше работы. При таком подходе вы должны использовать TaskFactory.FromAsync для создания Task -подходящих методов вокруг Begin/End пар. Затем используйте члены в возвращаемом Task<T>, чтобы запланировать доработки (Task.ContinueWith).

Недостаток оберточной подхода Task APM является то, что он никогда не использует контекст, так что если вы размещены на ASP.NET вы должны сделать свое собственное уведомление (SynchronizationContext.OperationStarted, SynchronizationContext.OperationCompleted). Вы также (возможно) должны захватить контекст (TaskScheduler.FromCurrentSynchronizationContext) и передать его ContinueWith, когда вы планируете свои продолжения, чтобы они работали в этом контексте.

Если вы создаете фактический компонент, который используется в остальной части кода, обертка подход Task APM имеет еще одно преимущество: он легче преобразовать в Task-based Asynchronous Pattern используемой async/await.