Silerlight で生成された WCF プロキシ クラスが非同期呼び出ししか提供しないのはなぜですか?
非同期パターンが本当に必要ない場合があります (たとえば、BackgroundWorker など)。
編集: 2 つの WCF 呼び出しの結果を処理する必要がある場合があります。両方の呼び出しが終了してから処理されるのを待つことができれば (アプリのビジネスがそれを可能にします)、はるかに簡単でした..しかし、いいえ....非同期! :P
Silerlight で生成された WCF プロキシ クラスが非同期呼び出ししか提供しないのはなぜですか?
非同期パターンが本当に必要ない場合があります (たとえば、BackgroundWorker など)。
編集: 2 つの WCF 呼び出しの結果を処理する必要がある場合があります。両方の呼び出しが終了してから処理されるのを待つことができれば (アプリのビジネスがそれを可能にします)、はるかに簡単でした..しかし、いいえ....非同期! :P
私が理解しているように、ここでの目的は、人々が間違ったことをするのを難しくすることです (UI からの同期 IO)。WCF クラスを使用している場合は、おそらくそれを使用する必要があります。
実際には、少なくとも「メイン」ブラウザー スレッドから同期呼び出しを実行できない技術的な理由があります。これは、ブラウザーがすべてのプラグイン API 呼び出しを同じスレッドで呼び出すためです。ネットワーク コールバックを待機すると、ネットワーク コールバックが通過せず、アプリがデッドロックします。そうは言っても、同期 API は別のスレッドから開始された場合 (つまり、アプリケーションが最初に QueueUserWorkItem を実行してブラウザー スレッドから降りた場合) に問題なく動作しますが、同期オプションを提供してそれを 1 つだけにするのは混乱を招くと感じました。ときどき働く。
Andrei、非同期パターンを使用しても、コードの記述方法を単純化するだけで、4 つの非同期要求に夢中になることなく、読みやすく保守的な表現力豊かなコードを記述できる方法があります。このライブラリを見てください http://syncwcf.codeplex.com/