4

サービス層、ビジネス ロジック層、およびデータ アクセス層に分離された WCF サービスがあります。

DAL で例外が発生した場合、そこでキャッチする必要がありますか?それとも、サービス レイヤーに戻しますか? なぜ？

このシナリオでのクライアントの関与は無視してください。WCF サービスで例外をログに記録することだけに関心があります。

4

4 に答える 4

4

そのための用語があります - 例外シールド。基本的に、SYSTEM 例外が上位レベルに移動するのを防ぐ必要があります。これは、攻撃者にシステム アーキテクチャのビューを与える可能性があるためです。WCF Exception Shielding は、特定の種類の例外をキャッチし、それらを他の種類の例外に置き換えることができます。たとえば、StackOverflow 例外をキャッチして、カスタム SystemException に置き換えることができます。Enterprise Library を使用している場合は、これらの例外が置換されたときにログに記録するように構成することもできます

Enterprise Library 3.0 での例外処理ブロックの使用

于 2010-06-23T14:13:54.573 に答える
3

また、ソリューションをどのように設計しているかにも依存します。たとえば、DALレイヤーとBLLレイヤーが完全に独立したコンポーネントであることが意図されている場合、誰がそれらを呼び出しているかについて推測することはできません。そのため、両方ともコンポーネント境界で例外をキャッチし、それらの例外をログに記録してから、例外を伝播できるようにする必要があります。一般的な例外をレイヤー固有の例外でラップしたい場合があります。

catch (Exception ex)
{
    Logger.Log(ex);
    throw new DalException("Unhandled exception in DAL", ex);
}

これらがアプリケーション全体の一部としてのみ使用されることがわかっている場合は、ログ記録を最外層（例外をキャッチしない場合は例外がログに記録されない層）に延期できます。

于 2010-06-23T15:09:11.197 に答える
3

それは、サービスがどのように消費されるか、および例外が発生したときに誰に知らせたいか (もしあれば) に依存すると思います。

たとえば、ミッション クリティカルな社内ビジネス アプリケーションを開発している場合、エンド ユーザーが開発者に連絡して迅速に対応できるように、アプリケーションを使用するユーザー インターフェイスに例外の詳細をサービス レイヤーからバブリングする必要がある場合があります。問題を解決します。

ただし、サービスが公開 Web ページで使用されているとします。おそらく、何らかの方法でサービス層にエラーをキャッチさせたいと考えていますが、最小限の情報をエンド クライアントに渡し、一般的なエラー メッセージをエンド ユーザーに提供し、例外の詳細をエラー ログに書き込むことを選択することもできます。レビューする開発者。

最終的には、例外をサービス層までバブルアップさせたいと考えていますが、例外をどのように処理し、エンド クライアントに渡す情報を決定するかはあなた次第です。

于 2010-06-23T14:15:14.407 に答える
1

私は通常、構成ファイルの ServiceBehavior によって Web サービスにアタッチされた一般的なエラー ハンドラー (System.ServiceModel.Dispatcher.IErrorHandler実装) を使用します。

このIErrorHandler.ProvideFaultメソッドは、サービスからスローされた例外をインターセプトし、次のことを行います。

  • それらをログに記録します。

  • FaultExceptions をそのまま渡します。

  • BLL によってスローされた "ビジネス" 例外 (ビジネス ルール違反など) を、フォールト コード "sender/client" を持つ FaultExceptions に変換します。

  • 技術的な例外 (DAL によってスローされたものなど) を、フォールト コード「レシーバー/サーバー」を含む FaultExceptions に変換します。

このように、サービス コード自体にはビジネス コードのみが含まれ、例外をキャッチする必要はありません。

于 2010-06-23T14:56:55.250 に答える