ユーザー名に一意の制約があるUsersテーブルがあります（明らかな理由で）。
EF 4.0 DALを使用してデータベースにデータを入力し、CreateUser（）メソッドをコーディングしています。
それは...ですか...
- すでに存在するユーザー名を挿入しようとした場合にスローされるSqlExceptionをキャッチするのが最善です。
- データベースに挿入する前に、ユーザー名を明示的に確認しますか？
理由も教えていただければ、それは素晴らしいことです。
4 に答える
3
レコードが最初に存在するかどうかを確認します。一意のキー制約は、アプリケーションが最初に「不良」データを許可する可能性のある方法を防ぐのに役立ちますが、その主な目的ではありません。回避できる場合は、制御フローメカニズム（この場合は検証）として例外を使用することは一般的に悪い考えです。
編集：混乱を避けるために、私は一意のインデックスをまったく持っていないと言っているのではありません。そこにあるはずですが、一意性をチェックするための主要な手段であってはなりません。
于 2010-11-05T03:06:29.540 に答える
2
例外を処理するのが最善だと思います。データベースはユーザー名の一意性を処理するように設計されているので、あなたよりも効率的に処理できると思います。また、システムに移植性とまとまりを追加します。複数の場所にユーザーを追加する場合は、ユーザー名チェックを複製するか、メソッドを作成する必要があります。基本的に、データベースエンジンが既に書き込んだ内容を書き換えることになります。
于 2010-11-05T03:07:07.067 に答える
1
サミュエルが言ったことに加えて、チェックしてからデータベースにレコードを追加するまでの間に、あなたのレコードと競合する可能性のあるレコードを誰も入力しないようにする必要があります。これはロックで実現できますが、ロックが原因で発生した例外をキャッチする必要があります。
ビジネス ルールとデータベースの複製に関しては、ビジネス レイヤーで一部の複製が行われるとしても、データベースに必要なだけの一貫性チェックが実装されていることを支持します。データベースが無効なデータに対してより厳密にロックされているほど、より良い結果が得られます。これにより、サポート担当者が SSMS を使用してデータベースに変更を加え、ユーザーから報告されたデータの問題を修正するなど、アプリ以外のツールを介してデータベースにアクセスすることから保護されます。
于 2010-11-05T10:02:46.093 に答える
0
私はサミュエルが言ったことに賛成です。最も効率的な方法は、データベースに任せることです。他のすべてのオプションは、より多くの時間とリソースを消費します....
于 2010-11-05T03:19:37.233 に答える