BLL、DAL、またはPLのどこで例外を処理する必要がありますか？

Question

例外を処理するのに最適な場所はどれですか？BLL、DAL、またはPL？

DALとBLLのメソッドが例外をチェーンの上位にスローし、PLに処理させる必要がありますか？または、BLLで処理する必要がありますか？

例

「ExecuteNonQuery」を発行して一部のレコードを更新するメソッドがDALにあり、1つ以上の理由により、0行が影響を受けます。ここで、例外が発生したかどうか、または条件に一致する行が実際になかったかどうかをPLに通知するにはどうすればよいですか。PLコードで「trycatch」を使用して例外を通じて通知する必要がありますか、それともDALで例外を処理し、（-1）のような特別なコードを返して、PLに（例外）と（no行が一致した条件、つまり影響を受けた行がゼロ）？

Answer 1

DALバブルでスローされた例外をPLまで許可することは意味がありません。データベース接続を確立できなかった場合、ユーザーはどのように対応する必要がありますか？

例外を早期にキャッチして処理します。処理できる場合は。ヒントやログメッセージを出力せずに飲み込むだけではいけません。これは深刻な問題やバグにつながり、追跡が困難になります。

Answer 2

これは多くの不必要な論争を伴う巨大なトピックです（大きな声で悪い情報を与える人々！）それに対処する気があるなら、s1mm0tのアドバイスに従ってください、それはほとんど賛成です。

ただし、一言で答えたい場合は、 PLに入れてください。深刻です。それを回避できる場合は、エラー処理をグローバル例外ハンドラーに入れます（すべてのエラーはログに記録され、セキュリティ上の理由から本番環境でログを検索するコードを提供する必要があります（特にWebの場合）が、開発中に完全な詳細を提供します速度の理由）。

編集:(説明） どこでもいくつかのエラーに対処する必要がありますが、これは「すべての機能」の基準ではありません。ほとんどの場合、PLにバブルアップし、独自のコードで.NETのグローバルエラーを処理します。イベントハンドラーを介して3つのレイヤーすべてからアクセスできる共通ルーチンを介してそこから完全な呼び出しスタックをログに記録します（メッセージの下部にある編集を参照） ）。これは、すべてのコードに試行/キャッチが散らばることがないことを意味します。予期してエラーが発生し、そこですぐに処理できるセクション、またはエラーをログに記録してユーザーに使用できない機能を通知する非クリティカルセクション（これはさらにまれで、非常に信頼性の高い/クリティカルプログラムの場合）

それとは別に、限られたリソースのアイテムを扱うときは、「using」キーワードを使用するか、キャッチなしでtry / final / endtryを使用することがよくあります。マルチスレッドロック/ミューテックス/再突入防止フラグなど。また、プログラムが引き続き機能するように、すべての場合でtry / finalを実行する必要があります（特にステートフルアプリ）。

例外を不適切に使用している場合（たとえば、IFステートメントを使用する必要があるときにバグ以外を処理したり、試してみる前にiffy操作が機能することを確認したりする場合）、この哲学はさらに崩壊します。

補足として、シッククライアントアプリでは、特に大量のデータやユーザーの入力が失われる可能性がある場合は、データを保存しようとする試行/キャッチを増やす方がよい場合があります（まだマークされていません-もちろん有効です。

編集：少なくともPLにロギングルーチンがある必要があります。これはプラットフォームによって動作が異なります。私たちが取り組んでいるアプリは、BLL / DALを3つのPLバージョン（ASP.Netバージョン、winformsバージョン、およびコンソールアプリバッチモード回帰テストバージョン）と共有しています。呼び出されるロギングルーチンは実際にはBLLにあります（DALはエラーをスローするか、エラーを取得または再スローするものを完全に処理します）。ただし、これにより、PLによって処理されるイベントが発生します。 Webでは、サーバーのログに記録し、Webスタイルのエラーメッセージ表示（本番用のわかりやすいメッセージ）を実行します。 WinFormsでは、テクニカルサポート情報などを含む特別なメッセージウィンドウが表示され、バックグラウンドでエラーがログに記録されます（開発者は「秘密」で何かを実行して完全な情報を確認できます）。そしてもちろん、テストバージョンでは、それははるかに単純なプロセスですが、同様に異なります。
パラメータ「whatplatform」を渡すことを除いて、BLLでそれをどのように行ったかはわかりませんが、ロギングが依存するwinformsまたはaspライブラリが含まれていないため、それでもトリックになります。

Answer 3

簡単な答えは状況によって異なります！

例外を処理できるのは、それを使って何か役立つことができる場合だけにしてください。 「何か役に立つ」ことは、あなたが何をしているかに依存します。例外の詳細をログに記録することをお勧めしますが、これは実際には処理されていないため、ほとんどの状況でログに記録した後、例外を再スローする必要があります。例外にさらに情報を追加するために、例外を他の（場合によってはカスタムの）例外でラップすることもできます。 @mbeckishが触れているように、たとえば操作を再試行することで例外からの回復を試みることができます。ただし、永久に再試行しないように注意する必要があります。最後に（駄洒落を許して）、finallyブロックを使用して、開いているDB接続などのリソースをクリーンアップすることをお勧めします。例外を除いて何を選択するかは、それを処理する場所に影響します。エラーが発生したことをユーザーに報告する以外に、多くの例外を除いて実行できる便利なことはそれほど多くない可能性があります。その場合、UIレイヤーで例外を処理することは許容範囲を超えます。問題をユーザーに報告します（おそらく、レイヤーのさらに下にある例外もログに記録する必要があります）。

自分で例外をスローする場合、例外のスローには大きなオーバーヘッドがあるため、「例外的な」状況でのみ例外をスローする必要があります。あなたの例では、操作によってレコードが更新されない場合に例外をスローすることを考えているかもしれません。これは本当に例外的ですか？この状況で行うより良い方法は、更新されたレコードの数を返すことです-これはユーザーに報告する必要があるエラー状態である可能性がありますが、DBへの接続が原因でコマンドが失敗するなどの例外ではありませんダウンしました。

これは例外処理のベストプラクティスに関する合理的な記事です。実践。

Answer 4

物事を正しく設定するために何をすべきかを知っているレイヤーは、例外を処理するレイヤーである必要があります。 たとえば、クエリを特定の回数再試行してデッドロックエラーを処理することにした場合は、それをDALに組み込むことができます。それでも失敗する場合は、例外を次のレイヤーにバブルアップさせて、このレイヤーがこの例外を適切に処理する方法を知っているかどうかを判断できるようにすることができます。

Answer 5

アプリケーションのすべてのレイヤーは、例外を適切に管理する必要があります。これは、すべてのレイヤーに表示されるため、横断的関心事として知られています。 Enterprise Exception Blockのようなフレームワークを統一して使用すると、全体的に優れたコードが得られると思います。 この投稿をご覧ください

http://msdn.microsoftcom / en-us / library / ff664698（v= PandP.50）.aspx

習得するにはしばらく時間がかかりますが、その周辺には多くの例とスクリーンキャストがあります。

Answer 6

例外の処理方法は、技術的およびビジネス上のニーズによって異なります。複雑または非常に重要なデータベースの更新については、既知のエラーのバックアップの小さなリストをDLに渡すパラメーターを含めます。このようにして、既知のエラーシナリオをプログラムで解決できる場合があります。それ以外の場合は、エラーをログに記録する必要があり、ユーザーにエラーを通知する必要があります。

私は人間に誤りを通知する練習をします。確かに、ロギングは詳細な情報を提供しますが、それは人間の応答時間に代わるものではありません。それだけでなく、なぜ開発者にシステムログを監視して、事態が悪化しているかどうかを確認するように強制するのでしょうか。不要なコストについて話します。

潜在的なエラー/例外を定義し、プログラムで解決する時間があれば、ぜひそれを実行してください。多くの場合、エラー/例外は予期しないものです。だからこそ、その予期せぬ事態に備えることが重要であり、それを行うには人間を巻き込むよりも良い方法があります。

全体として、例外処理を計画するときは、防御的である必要があります。プログラムは成長するか、死にます。成長の一部はバグの導入です。ですから、車輪を回してすべてを殺そうとしないでください。

Answer 7

あなたへの質問は、例外がどこに関連するかということです。データアクセス例外の場合は、DALでキャッチする必要があります。論理例外の場合は、BLLでキャッチする必要があります。プレゼンテーションの例外である場合は、PLで。

たとえば、DALが例外をスローした場合、nullまたはfalse、あるいはBLLに当てはまる場合は何でも返す必要があります。 BLLは、DALがnullを返した場合の対処方法を知っている必要があります。おそらく、DALがnullを通過したり、別の関数を呼び出そうとしたりします。BLLがDALからnullを通過したり、特定の何かを返したりした場合も、PLに同じことが言えます。独自の場合、プレゼンテーション層は問題が発生したことをエンドユーザーに通知できる必要があります。

もちろん、詳細な例外メッセージは表示されませんが、ユーザーに関する限り、これは良いことです。これらの例外をキャッチし、データベースやip：portなど、決定したものに報告するには、柔軟なロギングシステムが必要です。

基本的に、関心がデータである場合は、関心の分離の観点から考える必要があります。問題または論理的な問題は、それに応じて処理する必要があります。