15

アプリケーションでデータベースの例外をどのように処理しますか?
データを DB に渡す前に検証しようとしていますか、それとも単に DB スキーマの検証ロジックに依存していますか?
ある種の DB エラー (タイムアウトなど) から回復しようとしていますか?

いくつかのアプローチを次に示します。

  1. DB に渡す前にデータを検証する
  2. 検証を DB に任せ、DB 例外を適切に処理する
  3. 両側で検証する
  4. ビジネス ロジックのいくつかの明白な制約を検証し、複雑な検証を DB に任せる

どのようなアプローチを使用しますか? なんで？

アップデート:

議論が盛り上がって嬉しいです。
コミュニティの回答をまとめてみましょう。

提案:

他に何か言いたいことはありますか？これは検証固有の質問に変換されます。「データベース関連のエラーのベスト プラクティス」の核となる部分がありません。どのエラーを処理し、どのエラーをバブルアップするか?

4

7 に答える 7

6

@aku: DRY はいいけど、いつもできるとは限らない。検証は、UI 内、ビジネス ロジック内、およびデータベース内の 3 つの完全に異なる場所の 1 つです。

Web アプリケーションを考えてみましょう。サーバーへのトリップを減らしたいので、クライアント データ入力の JavaScript 検証を含めます。ただし、ユーザーが入力した内容は信頼できないため、データベースに触れる前にビジネス ロジック内で検証を実行する必要があります。また、データの破損を防ぐために、データベースには独自の検証が必要です。

これら 3 つの異なるタイプの検証を 1 つのコンポーネント内に統合する明確な方法はありません。

P&P グループのPolicy Injection Application BlockとValidation Application Blockを組み合わせたようなポリシー インジェクター内の検証など、分野横断的な責任を統一する試みがいくつか行われていますが、これらはまだコード ベースです。コードに含まれていない検証がある場合でも、並列ロジックを個別に維持する必要があります...

于 2008-09-02T13:06:00.343 に答える
4

クライアント側とデータベース側の両方で検証する決定的な理由が 1 つあります。それはセキュリティです。特に、AJAX やハッキング可能な URL などを使い始めると、サイト (この場合) がユーザーやハッカーにとってより使いやすくなります。

クライアントで検証してスムーズなエクスペリエンスを提供し、ユーザーに入力を修正するよう早期に伝えます。また、データベースのセキュリティのために、データベース (または、これがデータベースへの完全に安全なゲートウェイと見なされる場合はビジネス ロジック) で検証します。

于 2008-09-02T13:18:55.120 に答える
3

DB への不要なトリップを減らしたいので、アプリケーション内で検証を実行することをお勧めします。また、データが入力される UI の近く (コントローラー内か、単純なアプリの UI レイヤー内か) で、最も回復しやすい場所でデータ エラーを処理できます。

ただし、プログラムでチェックできないデータ エラーがいくつかあります。たとえば、データベースへのラウンドトリップなしでは、関連データの存在についてデータを検証することはできません。このようなデータ エラーは、リレーションシップ、トリガーなどを使用してデータベースで検証する必要があります。

データベース呼び出しによって返されたエラーを処理する場所は興味深いものです。データ層、ビジネス ロジック層、または UI 層でそれらを処理できます。この場合のベスト プラクティスは、これらのエラーを処理する前に、最後の責任ある瞬間までバブルアップさせることです。

たとえば、ASP.NET MVC Web アプリケーションがある場合、データベース、コントローラー、UI (モデル、コントローラー、ビュー) の 3 つの層 (下から上) があります。データレイヤーによってスローされたエラーは、コントローラーにバブルアップできるようにする必要があります。このレベルでは、アプリケーションはユーザーが何をしようとしているのかを「認識」し、ユーザーにエラーについて正しく通知し、それを処理するさまざまな方法を提案できます。データ層内でこれらのエラーから回復しようとすると、コントローラー内で何が起こっているのかを知ることがはるかに難しくなります。もちろん、UI 内にビジネス ロジックを配置することは、ベスト プラクティスとは見なされません。

TL;DR: どこでも検証し、最後の責任ある瞬間に検証エラーを処理します。

于 2008-09-02T12:54:23.993 に答える
2

私は両側で検証しようとします。私が常に従う 1 つのルールは、ユーザーからの入力を信頼しないことです。これに続いて結論を下すと、通常、フォーム/Webページでフロントエンドの検証が行われ、不適切な形式のデータでの送信さえ許可されません。これは単純なツールです。つまり、値をチェック/解析して、日付フィールドに日付が含まれていることを確認できます。そこから、私は通常、データ入力が送信方法のコンテキストで意味があるかどうかをビジネス ロジックにチェックさせます。たとえば、提出された日付は想定範囲内ですか? 送信された通貨の値は想定範囲内ですか? 最後に、サーバー側では、Foreign Key 制約と Indexes がすり抜けたエラーをキャッチできます。これにより、最後の手段として DB 例外が発生し、アプリ コードで処理できます。

于 2008-09-02T12:47:59.547 に答える
2

NHibernate (より良いのはActiveRecord ) などのオブジェクト リレーショナル マッピング (ORM) ツールを使用すると、データ モデルを適切な C# クラスとしてコードに直接組み込むことができるため、多くの検証を回避できます。フレームワークに組み込まれた優れたキャッシングと検証モデルのおかげで、データベースへのトリップも回避できます。

于 2008-09-02T13:09:47.903 に答える
1

一般的に、入力後はできるだけ早くデータを検証するようにしています。これは、ユーザーが「送信」または同等のボタンをクリックした後よりも早く、役立つメッセージをユーザーに提供できるようにするためです。
db 呼び出しを行うときまでに、渡すデータがかなり良好であることを期待しています。
ヘルパー メソッドを共有する 1 つのファイル (またはファイルのグループ) に db 呼び出しを保持するようにしています。これにより、プログラマー (私または他の呼び出しを追加する人) が例外に関する詳細とパラメーターをログに書き込むのができるだけ簡単になります。渡された など

于 2008-09-02T12:44:47.667 に答える
0

私が書いていた種類のアプリ (私は転職して以来) は、社内のファット クライアント アプリでした。
ビジネスロジックをクライアントに保持し、データベースでより機械的な検証を行うようにします（つまり、より高いレベルの検証ではなく、プロシージャの実行能力にのみ関連する検証）。
要するに、できるところは検証し、関連する種類の検証を一緒に保つようにしてください。

于 2008-09-02T13:05:42.747 に答える