0

.NET 4.5 に移行しており、リポジトリに async を追加することを検討しています。

interface IRepository<T>
{
    T Find(int id);
    Task<T> FindAsync(int id);
    IEnumerable<T> FindAll();
    Task<IEnumerable<T>> FindAllAsync();
    ...
}

実装では、DB、WebServices などを呼び出す可能性があります。

私の質問は、CancellationToken をサポートする必要がありますか?

(心配しないでください - FindAllAsync() はおそらく Rx ベースになるでしょう :) )

4

2 に答える 2

1

asyncまあ、間違いなくあなたのリポジトリに追加してください。私はasync世界を支配することに大賛成です。:)

CancellationTokenサポートは別の問題です。必要になる可能性が高い場合、または基盤となる実装 (DB/Web サービス) がサポートしている場合は、通常は提供します (その場合、実装は非常に単純なので、単に提供したいと思います)。

CancellationToken主要な実装を渡すだけでなく、オーバーロードを提供できることに注意してくださいCancellationToken.None。new CancellationToken()または、と同等のインターフェースのデフォルト値を指定することもできますCancellationToken.None。私は常にデフォルト値のアプローチを使用していましたが、オーバーロードがメソッド解決を許可するがデフォルト値が許可しない状況がいくつかあります (Action変数を に割り当てるなど)。myRepository.FindAllAsync

于 2013-01-17T17:50:15.477 に答える
0

私は同じ質問をするつもりでした。答えは「キャンセルが重要なシナリオであると信じている場合のみ」だと思い始めています. ユーザーまたはインフラストラクチャ サービスが処理中のクエリをキャンセルするほど長い時間がかかるリポジトリがあると思われる場合は、そうする必要があります。クエリの場合は想像できますが、ほとんどの更新と挿入は非常に迅速に行われると考えられます。そうでない場合は、いずれにせよ失敗した (タイムアウトになった?) タスクが発生する例外的な状態が原因である可能性があります。

CancellationToken のサポートを追加すると、すべての呼び出し元が CancellationToken を提供する必要があり、悪質なチェーン効果があります。

于 2013-01-17T13:34:22.593 に答える