2011-09-16 9 views
2

私は最初の本当のasp.net Webアプリケーションを開発しています。データベース制約違反をトラップして処理するための最良の場所と方法については悩んでいます。列に固有の制約があり、ユーザーがその固有の制約に違反するものを入力したとします。その列の値が存在するかどうかをチェックするためにデータベースを呼び出すか、それをデータベースに送り、例外をスローしてアプリケーションで処理させますか?アプリケーションコード内でデータベース制約を適用する

私は後者の答えが嫌いです。データベースに到達する前に、ビジネスレイヤでできるだけ多くのことを処理するのが理にかなっています。しかし、私のアプリケーションはすべてのテーブルに対して基本的なCRUD操作を実装するプロシージャによって駆動されるため、多少問題があります。ですから、私がビジネスレイヤー内で一意性を強制するためには、すべての可能な制約のためのプロシージャーを作成して、更新または挿入の前にルックアップを行う必要があります。ちょっと退屈なように思えます...ビジネスルールはデータベースとビジネスレイヤの両方に存在するため、ビジネスルールを複製していますので、何か変わっただけではデータベースを変更する必要はありません。アプリケーションコード。

アプリケーションコードにこれらのデータベース制約を適用するには正しい方法がありますか、またはデータベースによってスローされた例外をキャッチしてユーザーフレンドリーな方法で表示する方法を検討する必要がありますか?

+0

お返事ありがとうございます。一意性をチェックするためにデータベースに戻らなければならないと考えると、意味があります。次のことは、データベースの例外を処理し、ユーザーフレンドリーな方法でそれらを提示し、ユーザーにあまり情報を公開しない方法を理解することです。 – Pmosh

+0

鍵は、DBMS( "データベース"ではなく)* IS * "ビジネス層"という概念を受け入れることです。 Toon Koppelaarsの "The Helsinki declaration"と呼ばれるもののGoogle。彼はそれがなぜ最良の選択肢であるか私が今までに見てきた最良の説明を持っています。 –

答えて

2

後者の回答は正しいです。フロントエンドアプリケーションですべてを試してやる場合、データベース制約を使用する目的は何ですか?

制約のポイントは、データがどこにどこに到達するかにかかわらず、できるだけ多くのデータ検証を一貫した方法で処理する中央の場所(DBサーバー)を持つことです。フロントエンドアプリケーションで同じロジックを全面的に書き込むことは冗長であり、不必要に複雑です。 DBの制約が変わった場合(あなたのアプリはもはや有効ではないと思っているもの)とにかく例外が出ます。

DBで検証制約を処理し、コード内の例外を処理させます。これにより、DBがそれを処理するため、データにアクセスして更新するために使用するすべての手段が一貫性を持つようになります。何か変更があった場合は、DBを新しい制約で更新すると、アプリは自動的に同期します。

0

私は、データベースをどのように使用しているかについてのあなたの説明が後者であることに同意します。更新/挿入を実行する前にビジネスレイヤから呼び出しを行って制約の違反をすべて検証した場合でも、他のユーザーからの要求と更新/更新のためにデータベースの状態が1秒後に変更される可能性があります。挿入が失敗する可能性があります。

関連する問題