7

私は標準の 3 層 ASP.NET Web アプリケーションを構築していますが、どこで特定のことを行うべきか、特に例外を処理するのに苦労しています。

いくつかの例について Web を調べてみましたが、すべてがどのようにリンクされているかを示すプロジェクト全体にまで及ぶものは見つかりませんでした。

私のデータ層では、SQL Server に接続していくつかのことを行っています。結果として発生する可能性のある例外をキャッチする必要があることはわかっていますが、どこでそれを行うべきかわかりません。

私が読んだことから、UI層でそれを行う必要がありますが、その場合、データベースへの接続が閉じられていることを確認する方法がわかりません. これを行う方法を明確にできる人はいますか？また、ベスト プラクティスに従った 3 層 Web アプリケーションの例をどこで見つけることができるかを誰かが知っていれば、それも素晴らしいでしょう。

ありがとう

4

4 に答える 4

6

確実に成功するための簡単な答えやパターンはありません。検証戦略と同様に、正確な例外処理戦略は正確な状況に固有であり、多くの場合、時間と包括性のトレードオフになります。ただし、私たちが提供できる良いアドバイスがいくつかあります。

  • スタック トレースを非表示にしないでください。セキュリティ上の目的で何が起こったかを隠したい場合を除き、「Rethrow」を使用しないでください。
  • どこでもエラー処理が必要だとは思わないでください。デフォルトでは、下位層では、実際のエラーを上位層まで浸透させることは悪くありません。UI/コントローラーは、問題が発生した場合の対応方法を実際に決定する必要がある場所です。
  • あらゆる点で、何か問題が発生した場合に、自分が正確に何をしたいのかを考えてください。多くの場合、最上位層またはクライアント マシンにまで移動させるよりも良い方法を思いつくことはできません。(ただし、詳細レポートの本番環境では。) これが当てはまる場合は、放っておいてください。
  • 管理されていないリソース (IDisposable を実装するもの) は必ず破棄してください。データ アクセスはその好例です。( A ) Final ブロッ​​クで (特に) 接続、コマンド、データリーダーなどに対して.Dispose ()を呼び出すか、( B )適切な破棄が行われるようにするSyntax/Pattern の使用を使用します。
  • エラーが発生する可能性が高い場所と、特定のエラーを探すことができる場所を探し、(再試行するか、2 回目の再試行を待つか、そのアクションを別の方法で試行するなどして) 反応し、うまくいけば成功します。例外処理の多くは、失敗を適切に報告するためではなく、成功を実現するためのものです。
  • データ層では、多段階のプロセスの途中で問題が発生した場合の対処法を検討する必要があります。実際のエラーを浸透させることはできますが、このレイヤーはエラー後の整理を処理する必要があります。トランザクションを使用したい場合があります。
  • 非同期の状況 ((A.) 複数のスレッドのため、または (B.) ビジネス ロジックが「タスク マシン」などで個別に処理され、後で処理されるため) では、特にエラーのログ記録の計画を立てる必要があります。
  • アプリの 100% よりも 25% に "エラー処理コード" が表示されることを望みます。100% は、おそらく、エラー処理が行われているように見えることを望んでいたことを意味します。25% は、実際に処理する必要がある例外の処理に時間を費やしたことを意味します。
于 2010-01-26T15:30:42.967 に答える
1

あなたの考えを導くかもしれないちょっとしたポイント: 同時実行性の問題 (デッドロック) を引き起こす可能性のあるタイプのボリュームがある場合、アプリケーションでその特定の SQL エラーを検出し、操作 (トランザクションなど) を再試行する必要があります。これは、データ層またはビジネス層のいずれかで何らかの例外処理が必要であることを示しています。

-クリップ

于 2010-01-26T15:24:06.883 に答える
1

最後の責任ある瞬間に例外を処理するのがベストプラクティスだと思います。これは通常、UI レベル (つまり、MVC アプリのコントローラーまたは従来の asp.net アプリの分離コード) を意味します。この高レベルで、ユーザーが何を求めているか、何かがうまくいかない場合に何をする必要があるかをコードが「認識」しています。

通常、コール スタックの下位で例外を処理すると、呼び出し元のコードが例外的な状況を適切に処理できなくなります。

データ層では、標準パターン (たとえば、SqlConnection などの IDisposablesのusingステートメント) を使用し、発生する可能性があることがわかっている例外を文書化して (メモリ不足やその他のまれなケースではこれを行わないでください)、それらを許可します。それらがそうするとき、呼び出しスタックを上にフローします。多くの場合、多くの例外を呼び出し元が処理する必要がある場合に、それらの例外をキャッチして単一の例外タイプにラップする必要があります。

例外を手放す前に「クリーンアップ」する必要がある場合は、いつでもfinallyブロックを使用してクリーンアップできます。ブロックcatchを使用するために必要はありません。finally

適切な例外処理を強調するように設計された小さな Web サイトの例を知りません。申し訳ありません。

于 2010-01-26T15:24:20.457 に答える
0

これはあなたの質問に対する具体的な回答ではありませんが、ベスト プラクティスに興味がある場合は、Microsoft のパターンとプラクティスを参照してください。

アプリケーション アーキテクチャ ガイド

Web アプリケーション ガイド

于 2010-01-26T16:21:59.870 に答える