3

TcpClient多くのクラス ( 、UdpClient、 などHttpListener) は、イベント ドリブンであれば理解しやすく使いやすかったと思います。またIAsyncResult、あらゆる種類の奇妙なユースケースが可能になるため、パターンを実装するのは非常に困難です。

  1. 呼び出し元が複数の Begin メソッドを続けて呼び出した場合はどうなるでしょうか?
  2. 呼び出し元が Begin メソッドと通常のメソッドを混在させるとどうなりますか?

等々。それにもかかわらず、マイクロソフトはほとんどの場所でそれを使用することを選択しました。なんで？

編集: .NET 2.0 についての議論に集中してください。

4

2 に答える 2

11

等々。それにもかかわらず、Microsoftはほとんどの場所でそれを使用することを選択しました。なんで？

を使用した非同期パターンIAsyncResultは、フレームワーク内で使用された元の非同期プログラミングパターンでした。それにはいくつかの利点があり、複雑さは時間の経過とともに開発される新しいパターンにつながりました。

イベント非同期プログラミング（EAP）は、後で導入されました（完了イベントを伴う「Begin」メソッドがあります）。これにより多くの複雑さが解決されましたが、ロジックを複数のメソッドに分割する必要があるため、多くの状況で使用するのは依然として困難でした。

ただし、現在の非同期パターンは.NET 4TaskとTask<T>クラスに基づいており、特にC＃5のasync/awaitサポートと組み合わせると大きな利点があります。幸い、TaskFactory.FromAsyncIAsyncResultを使用すると、ベースの非同期メソッドペアを簡単にTask<T>自動的にラップできるため、新しいパターンを使用できます。.NET 4.5は、を返すフレームワークの非同期メソッドの多くの新しいバージョンを追加したTask<T>ため、新しいasync/await言語サポートをフレームワークメソッドで使用できます。これは、すべての非同期プログラミングで前進するための推奨される方法です。

于 2012-10-05T16:43:00.810 に答える
4

このパターンには多くの長所はありません。

.Net 1.0では、ジェネリックスとラムダ式の前は、これが利用可能な唯一の非同期パターンでした。

When*()より現代的なタスクベースのパターンは、型の安全性、より単純なエラー処理、継続、メソッドなど、さまざまな理由ではるかに優れています。

于 2012-10-05T16:42:32.757 に答える