0

私のアプリケーションと私の WCF サービスとのすべての対話を処理するクラスがありますが、MSDN は、WCF での Using)_ ステートメントの使用は悪いと言っているようです。 /msdn.microsoft.com/en-us/library/aa355056.aspx)

私の問題は、彼らが提案する実装​​方法は、同じ構造コードを持つ [私のサービスの 10 個のパブリック メソッドとして] 10 個のメソッドがあることを意味し、これはもちろん DRY プリンシパルに従わないことです。コードは次のようになります。 :

try
{
    results = _client.MethodCall(input parameteres);
    _client.Close();
}
catch (CommunicationException)
{
    if (_client != null && _client.State != CommunicationState.Closed)
    {
        _client.Abort();
    }
}
catch (TimeoutException)
{
    if (_client != null && _client.State != CommunicationState.Closed)
    {
        _client.Abort();
    }
}
catch (Exception ex)
{
    if (_client != null && _client.State != CommunicationState.Closed)
    {
        _client.Abort();
    }
    throw;
}

これにはまだロギングがありませんが、もちろん、ロギングを開始するときは、ほぼ 10 の異なる場所でロギング作業を追加する必要があります。

ここでコードを再利用する際に、もう少し機知に富む方法についてのヒントはありますか

ありがとう

ポール

4

1 に答える 1

5

ロギング、再スローなどの基本的な例外処理処理を実際の処理場所から分離できるようにする、汎用の構成可能な例外処理コンポーネントを使用します。このようなコンポーネントの一例は、Microsoft のException Handling Application Blockです。

次に、次のようなコードになる可能性があります。

try
{
    results = _client.MethodCall(input parameteres);
    _client.Close();
}
catch (Exception ex)
{
    _client.CloseIfNeeded();
    if (!ex.Handle("Wcf.Policy")) throw;
}

whereCloseIfNeededは WCF チャネル クロージング ロジックをカプセル化するカスタム拡張メソッドを示し、Handle例外メソッドは例外処理メカニズムを呼び出し、この場所に適用される例外ポリシーの名前を渡します。

ほとんどの場合、例外処理ロジックを適切な 1 行または 2 行のコードに減らすことができ、いくつかの利点が得られます。

  • 例外処理動作 (ポリシー) の即時構成可能性
  • 特定のタイプの例外および例外ポリシーにバインドされたカスタム例外ハンドラーによる拡張性
  • コードの管理性と可読性の向上
于 2010-10-06T11:19:28.317 に答える