0

ファイルキャッシュ（各ファイルはサードパーティのAPIへのリクエストの結果を表す）として機能するWCFサービスを継承しました。現時点では、ファイルが存在しない場合、コードはデータを作成するための新しいリクエストを作成し、クライアントコードにも例外を発生させます。

クライアントがファイルを再度要求するために戻ってきて、それまでにクライアントがファイルを利用できるようになるという考えだと思います（ファイルの生成には数秒かかります）。

ここにコードの臭いがあると思うので、この部分を書き直さなければなりません。現時点では、いくつかの方法で例外が発生し、バブルが発生しています。ファイルが存在するかどうかをソースで確認し、その情報をコールスタックに渡す必要があると思います。

WCFインターフェースには現在GetValue()メソッドがありますが、それを置き換えるために使用できると思う2つのオプションがあります。

  1. nullファイルが存在しない場合に戻ります。
  2. bool TryGetValue(string key, out string value)メソッドを使用する

誰かが好み/推奨事項を持っていますか？

ありがとう

4

1 に答える 1

1

「TryGet」アプローチはもう少し明示的です。null を返すアプローチでは、メソッドがさまざまな理由で null を返すことを文書化する必要があり、これには開発者がドキュメントを読む必要があります。ご存知のように、ドキュメントを読むことにアレルギーを持っている人もいます。

「TryGet」アプローチのもう 1 つの利点は、bool ではなく列挙型を使用して、メソッドが失敗した (または成功した) 理由と方法について呼び出し元にさらに多くの情報を提供できることです。

Jeffrey Richter (C# の CLR) による例外の定義: アクション メンバーがそのタスクを完了できない場合、メンバーは例外をスローする必要があります。例外とは、アクション メンバーが、その名前で示されているように実行するはずだったタスクを完了できなかったことを意味します。私の質問は、クライアントが GetValue メソッドを利用できるようにして、データが利用できない場合にエラーを発生させるか、削除して TryGetValue() に置き換える必要があるかということです。

Jeffrey Richter の定義は、API の設計を決定する際には役に立ちません。これには、各アクション メンバーのタスクを決定することが含まれるためです。

あなたの設計では、当然のことながら値が利用できないことを期待しています。これは、値が利用できないことは例外的な状況ではないことを意味します。 したがって、TryGet... パターンのみを使用します。

しかし、正直なところ、私はまったく別のアプローチを追求します。誰かがこのアプローチを試みたとします:

while (!TryGetValue(key, out value)) {}

また：

SomeType value;
bool flag = false;
while (!flag)
{
    try
    {
        value = GetValue(key);
        flag = true;
     }
     catch {}
}

あなたの WCF サービスは、多くのヒットを得るでしょう。非同期モデルを調べた方がよいでしょう。そのため、サービスを継続的にポーリングするようにクライアントを招待するのではなく、結果の準備ができたときにコールバックを通じてクライアントに通知されます。

于 2012-05-08T14:33:51.753 に答える