さまざまな理由から、使用するサービスで非常に頻繁に HttpWebRequest クラスを使用してアウトバウンド HTTP 要求を送信するなど、既存の同期 IO バウンド コードを変更することを目指してきました。
async/await と .NET 4.5 への変更は認識していますが、現在は .NET 4.0 を使用しています。私は Microsoft.Bsl.Async も知っていますが、他の理由から、現在これはオプションではありません。
HttpWebRequestを使用した Async に関するこの記事のサンプル コードを参照として使用しています。
私が持っている質問は、UI を更新していないか、BeginXXXX と EndXXXX の間で他のことを行っていないが、アウトバウンド IO 呼び出しの時間がそれぞれ 40 秒以上かかる場合、この非同期を実装する価値があるか、それとも固執する必要があるかです。同期実行するには？
間違いなく価値があると言えます。これは、特にサーバー側では主観的な判断ですが、40 秒は非常に重要です。あなたのサービスが CPU バウンドではないと仮定すると、約 0.5 秒で十分に高速であり、同期することを検討できます。40 秒間、必ず非同期にします。
.NET 4.0 で ASP.NET を使用している場合は、Microsoft.Bcl.Async. ただし、サービスが別のもの (Win32 サービスなど) の場合は、Microsoft.Bcl.Async. いずれにせよ、可能であれば .NET 4.5 にアップグレードする計画を立ててください。あなたは、どれだけの痛みasyncがあなたを救ってくれるかを知ろうとしています。
コード構造に関しては、次の 2 つのアプローチのいずれかをお勧めします。
Taskのラッパーを使用します。EAP アプローチはよりクリーンです。EAP では、WebClient代わりにHttpRequest. たとえば、DownloadStringAsyncメソッドを呼び出してDownloadStringCompletedイベントを処理します。これの利点は、非同期操作が進行中であることを EAP が現在のコンテキストに通知し、操作が完了したときに再度通知し、そのコンテキストを使用してイベント ハンドラーを実行することです。これは、ASP.NET でホストされている場合に特に重要です。
EAP パターンの欠点は、(必要がない場合でも)常にコンテキストを使用することです。
APM ラッパーのTaskアプローチは、もう少し手間がかかります。このアプローチでは、/ペアの周りに -returning メソッドTaskFactory.FromAsyncを作成するために使用します。次に、返されたスケジュール完了のメンバーを使用します( )。TaskBeginEndTask<T>Task.ContinueWith
TaskAPM ラッパー アプローチの欠点は、コンテキストを使用しないことです。そのため、ASP.NET でホストされている場合は、独自の通知を行う必要があります ( SynchronizationContext.OperationStarted、SynchronizationContext.OperationCompleted)。また、(おそらく) コンテキスト ( ) をキャプチャし、継続をスケジュールするときにTaskScheduler.FromCurrentSynchronizationContextそれを渡して、そのコンテキスト内で実行する必要があります。ContinueWith
コードの残りの部分で使用される実際のコンポーネントを作成している場合、 APM ラッパー アプローチには別の利点があります。それは、 /で使用されるタスク ベースの非同期パターンTaskへの変換が容易になることです。asyncawait