2

列の1つに一意キー（または他の）制約があるSQLテーブルがあるとします。

次に、ユーザーがこの列を編集できるようにするアプリケーション（ASP.NET MVCを使用します）があります。

ユーザーが保存しようとして、制約が破られる/破られる場合は、ユーザーにわかりやすいエラーメッセージを表示する必要があります。そのため、次のうちどれがより良い習慣ですか？

  1. アプリケーションにデータベースにクエリを実行させて、制約が破られていないことを確認してから、行を挿入/更新します（データベースへのクエリが2つ発生します）

    また

  2. すぐに挿入/更新の実行を試み、制約が破られた場合はSqlExceptionをキャッチします。データベースへのアクセスが1回しかないため、これが好きですが、どのインデックス/制約が壊れているかをどのように抽出し、適切なメッセージを添付する必要がありますか？（Exception.Messageの検査は別として？）

4

2 に答える 2

1

1 はより優れたオールラウンド ソリューションです。コストのかかる操作は Db 呼び出しだけではなく、例外もコストがかかります。ユーザーのアクションではなく、コードが原因で何か問題が発生した場合にのみ、データベースに例外をスローさせる必要があります。

たとえば、後で Elmah をインストールして、例外をログに記録したり、メールで送信したりしたいと思うかもしれません。Elmah は、明示的にそうしないように指示しない限り、そのような例外を記録/メールします。

さらに、あなたが言ったように、例外は常にユーザーに伝える最もビジネス的な情報を持っているとは限りません (特に SQL 固有の SQL 例外)。理由により、これらの固有の制約やその他の制約があります。これらの理由から、情報を保存する前に検証してください。

twitter や gmail などを考えてみましょう。ユーザー名を取得しようとすると、アプリケーションはまずそれが使用されているかどうかを確認します。これらは、アプリケーション レベルでの一意性制約であり、最終的に SQL 制約として実現される場合とされない場合があります。ユーザーと向き合うのはアプリケーションであるため、SQL から英語に翻訳してユーザーとコミュニケーションを取ろうとしてはなりません。

于 2012-07-19T07:49:21.817 に答える
0

オプション1の問題は、アプリケーションが制約とは何かについて個別の明確な知識を持っている必要があることです。これはDRYの原則と矛盾し、後でデータベースの制約が変更され、アプリケーションが更新されない場合に問題が発生する可能性があります。データロジックとアプリケーション間の緊密な結合。また、実行された制約チェックが、その後の更新を試行したときに後続のポイントで引き続き有効であるという保証はありません。

これは、コミットが試行される前にユーザーを支援するために、UIレイヤー検証を使用してアプリケーションを拡張することを妨げるものではありません。

したがって、それが破棄された場合、オプション2が残り、アプリケーションのどこかで翻訳が必要になります。その翻訳とそのロジックをどこに配置するかは、保存された手順またはビジネスロジックレイヤーのどちらであっても、あなた次第です。

于 2012-07-19T12:46:28.723 に答える