パラメータの検証、ストアドプロシージャ、データアクセスレイヤー＃

Question

私は、C＃とSQL Serverデータベースを3つの階層アーキテクチャで使用しています。 DRYプリンシパルによれば、検証は、私の場合、フロントエンドのデータアクセス層またはデータベースのストアドプロシージャのいずれかである1つの場所で行う必要があります。

私はデータアクセス層でストアドプロシージャのパラメータを検証するのか、それともストアドプロシージャ自体に残すのかしら？

Answer 1

DRYは重要な原則ですが、defence in depthです。

入力の検証に関しては、安全であることを確認する必要があります。これは、各レベル（DALとストアドプロシージャの両方）で行う必要があります。

ビジネスロジックのデータの検証に関しては、ビジネスロジックレイヤー（BLL）に配置する必要があります。

Answer 2

3層アーキテクチャを使用している場合は、代わりにNhibernateやLinq to EntitesなどのORMを使用することを検討することをおすすめします。 ORMは、より良いリファクタリング能力と保守性を提供します（私の保守性は、私の経験に基づいて、長期的には品質につながるので、最も重要なことです）。

あなたのDAL（データアクセスレイヤー）であなたのセキュリティをバイパスすることがより簡単にできるより安全なので、あなたの検証をUIに入れるのは賢明ではありません）。 SQLインジェクションについて考える。 UI上で見逃しやすいようなUIのみではなく、アクセスが許可されていない他のデータにアクセスしようとする悪意のあるユーザーとして簡単に迂回することができます。

ユーザービリティのためにUI上に、そして安全のためにデータアクセスレイヤーに潜在的にバリデーションを持つことは意味があると思います。私はDRYプリンシパルが1つの場所で妥当性検査をしているのが好きですし、あなたはまだそれを行うことができます。データアクセスレイヤーとUIの両方に適用される共通のルールセットを作成すると、（データ入力の即時のフィードバックを通じて）安全で使いやすいシステムが得られます。他の方法では、異なるレイヤーに対して異なるルールを持つことができます。例えば、フィールド長ルールおよびデータ入力パターンは、UI特有のものとすることができる。 DALは、例えば、データが有効であることを強制することができる。複数の場所でバリデーションを行っていますが、別々に同じことをしていない限り、あなたは大丈夫だと思います。これは、バリデーションがクロスカッティングの問題であり、アプリケーション設計の残りの部分をどのように構成するかに大きく依存するため、アプリケーションを設計する際に考慮すべき最も難しい領域の1つです。