私のアプリケーションは 3 つのレイヤーで構成されており、非常に簡単です。
- すべてのビジネス ロジックを含むクラス ライブラリ
- クラス ライブラリを公開する WCF サービス
- asp.net Web UI。
クラス ライブラリ レイヤーでは、エンタープライズ ライブラリの例外処理ポリシーを定義して、すべての例外をデータベースに記録します。基礎となるコードでは、例外がスローされ、ファサードに結合されます。ファサードでは、EL ポリシーをトリガーしてエラーをログに記録します。次に、応答で sucessStatus ブール値を切り替え、すべての例外をわかりやすいリストに変換するメソッドを用意して、最終的な消費者がこれを掘り下げてアイデアを得ることができるようにします。何が起こっているのか。
私のクラス ライブラリのファサードは、次のようになります。
public SomeResponse DoSomething(SomeRequest request)
{
SomeResponse response = new SomeResponse();
try
{
response.data = SomeOperationThatWillThrowAnException;
}
catch (InvalidOperationException ex)
{
var exceptionManager = EnterpriseLibraryContainer.Current.GetInstance<ExceptionManager>();
exceptionManager.HandleException(ex, "StandardPolicy");
response.Errors.Add(Utility.ExceptionToError(ex));
response.SuccessStatus = false;
}
return response;
}
単純な winform クライアントを作成してクラス ライブラリと通信させると、これは機能します。
ただし、フルスタックを使用すると、「fault exception was unhandled by user code」というメッセージが表示されます。これが起こらないようにするために、WCFレイヤーでELを構成することはできないようです。
私の WCF サービスは、私のクラス ライブラリ ファサードの単なるラッパーです。
public SomeResponse DoSomething(SomeRequest request)
{
return new MyFacade.DoSomething(request);
}
私が望むのは、クラス ライブラリがエラーを黙って処理し、WCF または UI レベルで例外をトリガーしないようにすることです。コンシューマー (この場合は ASP.NET Web フォーム UI) が応答メッセージの内容をチェックして、例外が実行を停止する代わりに、何が起こったかの手がかりを得る必要があることを望んでいます。