2

次のようなものを含めることができるビジネスロジックレイヤーに検証ロジックを配置することを計画しています。

[Required], [Length > 0]など。データ注釈の使用。ただし、DAL をデータベースに挿入する前に、オブジェクトが重複していないことを確認する検証ルールも必要[IsDuplicate]です。では、問題は、[IsDuplicate] 検証ルールをどこに置くかということです。これを BL に入れると、BL が DAL を認識しない現在の 3 層セットアップに違反します。重複のチェックは検証ルールまたは何か他のものと見なされますか?

4

3 に答える 3

0

私は、ウルトラセーフをプレイするのは息苦しいと考えています。BL でのみ重複チェックを行い、オブジェクトのリスト全体を dal 呼び出しで取得します。ただし、オブジェクトのリストが大きすぎる場合は、ストアド プロシージャ/DAL レイヤーで dupecheck を実行する必要がある場合があります。

于 2013-05-24T00:20:47.570 に答える
0

あなたの質問はあいまいです。どのような記録、どのような操作を参照するかによって異なります。

次のように、 1 対多のレコードを参照する場合:

header --> many details

BL

次に、 BLで重複チェックが行われます。つまり、たとえば、ヘッダーの詳細に同じ項目コードが 2 つ以上含まれてはならないかどうかなどを検証します。また、プロセスがヘッダーの配列を受け入れる場合、重複したヘッダーの検証もBLで行われます。

最小長、文字列形式、null 値などの他の検証規則もBLで行われます。いくつかの制約とデータ長/ isnull データ型を使用している場合でも、 DBで自動的に再検証できます。

ダル

ただし、ヘッダー ID がDBに既に存在するかどうかを検証する場合は、DALで行います。これは、BLがリポジトリに何があるかを知らないためです。DALの責任です。

ただし、最初に検証を行う必要がない場合もあります。たとえば、ヘッダー テーブルに既に一意のインデックスがある場合、例外がスローされ、それをキャッチするだけで済みます。ただし、アイテムが存在しない、アイテムの金額が十分でない、特定のユーザーが存在しないなどの特定のDB検証チェックの場合は、 DALで実行するか、ストアド プロシージャを使用する必要があります。

ただし、DALの検証はBLから呼び出す必要があり、 UIからの直接呼び出しは避けてください。

于 2013-05-24T04:31:07.867 に答える