16

新しい async/await パターンを理解しようとしているのですが、答えが見つからない質問が 1 つあります。つまり、メソッドを async でデコレートする必要があるのか​​、他の async 関数からそれらのメソッドを呼び出すつもりなのか、またはTasksを返すだけなのかということです。適切な場において？

言い換えれば、これらのクラス A、B、または C のどれが最適で、その理由は?

class A<T>
{
      public async Task<T> foo1() //Should be consumed
      {
          return await foo2();
      }

      public async Task<T> foo2() //Could be consumed
      {
          return await foo3();
      }

      private async Task<T> foo3() //Private
      {
          return await Task.Run(...);
      }
}

class B<T>
{
      public async Task<T> foo1() //Should be consumed
      {
          return await foo2();
      }

      public async Task<T> foo2() //Could be consumed
      {
          return await foo3();
      }

      private Task<T> foo3() //Private
      {
          return Task.Run(...);
      }
}

class C<T>
{
      public async Task<T> foo1() //Should be consumed
      {
          return await foo2();
      }

      public Task<T> foo2() //Could be consumed
      {
          return foo3();
      }

      private Task<T> foo3() //Private
      {
          return Task.Run(...);
      }
}

メソッドを過度に装飾するのは冗長に思えるので、自然に に傾倒しますCが、同時に、キーワードTask<T>を使用しないと操作するのが少しぎこちなく感じられます。await

4

2 に答える 2

9

どちらのバージョンも効果的に同じように機能します。唯一の違いは、awaitここで使用するとパフォーマンスが低下することです (ステート マシンをセットアップする必要があり、継続が使用される可能性が高いため)。

したがって、それはトレードオフになります: 可読性がわずかに低下するという代償を払って、メソッドをいくらか効率的にしたいですか? それとも、読みやすさのためにパフォーマンスを犠牲にしても構わないと思っていますか?

通常、最初に読みやすさを重視し、プロファイリングで価値があることがわかった場合にのみパフォーマンスに集中することをお勧めします。しかし、この場合、読みやすさの増加は小さいと思うので、おそらく使用しないでしょうawait。

Cまた、クラスがまだ十分に進んでいないことにfoo1()注意してくださいawait。

于 2012-08-18T07:54:01.380 に答える
2

シグネチャのは、一般的なケースでセマンティクスasyncを実装するために必要な、含まれているコードの状態マシンの書き換えをコンパイラが作成できるようにするためにあります。await

あなたの例は、まさにその書き換えを必要としない特別なケースです。非同期操作は、メソッド内で最後に発生することです。そのような方法はすでに可能であり、 で有効です.NET4.0。asyncこの互換性は、不要なときに避けるべき理由の 1 つかもしれません。

于 2012-08-18T07:18:33.873 に答える