パターンの形で存在する検証

Question

MVCがあるとします。われわれのCはスマートで、ルータとしてしか機能しません。ビジネス層では、Persistenceレイヤー-DAOを呼び出します。

私たちは検証を行います。モデルやDTOクラスのフィールドに配置されたアノテーションベースの検証については言及していませんが、バリデータクラス自体を作成する場合のようにもっと複雑なものです。どのように正式な図でそれを説明しますか？私はそれがビジネスロジックの中にあると考えました。しかし、Spring MVCの検証と同時に、コントローラの方がより重視されます。

あなたが適切だと思うものはすべてお知らせください。

Answer 1

私は、検証に関する懸念もプレゼンテーション、ビジネス、データベースなどのレイヤーで構成されていると感じています。

レイヤの名前は、最初に検証ルールに何も意味しません。 （妥当性検査のルールがチェックされているレイヤーであることを意味します）

私は主にWebアプリケーションを開発していますが、このルールはそのようなアプリケーションのためのものですが、

データベースレイヤ検証ルールを：バッチジョブのようなもの

は、下から上へ行くことができます。 これらは主に "not null"（フィールドとリレーション用）です。このレイヤーでは、すべての検証制約が存在します（また、データベースによって強制されます）。これは、実装そのものにとって必須です。これは、アプリケーションがクラッシュする検証違反がある場合を意味します。 （それは、ビジネスロジックが何かを間違って計算することを意味するものではなく、実際にはアプリケーションが結果を返さないことを意味します）。 Database Layerの検証ルールで、このレイヤーのルール違反がバグを意味することを理解することは重要です。したがって、これらのルールの目的は確認することではありません。その目的は、重大な検証違反が永続化されないようにすることです。データベースレコードがロードされるたびにアプリケーションがクラッシュすることはありません。 - したがって、この制約の違反は直接未解決の例外につながります。原因はバグであり、間違ったデータベースレコードを修正することは不可能であるためです。

ビジネス層検証 この検証規則は、主にサービス機能にビジネス層に存在します。 「ユーザー名は一意でなければならない」のようなものです。このルールに違反してもプログラム自体はクラッシュしませんが、ビジネス上の結果が間違っている可能性があります。もう1つ重要なことは、Bussiness Layer Validationルールはデータベースによっても適用できることです。しかし、未解決の例外の代わりに、違反の例外をキャッシュして処理する必要があります。ビジネス層のバリデーション違反はバグではなく、誤った入力です。

プレゼンテーションレイヤの検証 この検証ルールは何も意味しないルールです。ほとんどの場合、毎日変更されるいくつかの愚かなビジネスルールであり、ビジネス結果には影響しません。これらは次のようなルールです： "スタックオーバーフローの質問へのコメントは少なくとも10文字以上でなければなりません"。 私はこれらのルールをプレゼンテーション層でのみチェックします（もちろんサーバー側で）。

もちろん、ビジネス層またはデータベース層の制約は、（あまりにも多くの作業を行うことができる限り）プレゼンテーション層の入力フォームでもチェックする必要があります。たとえば、nullでなくてはならないフィールドがある場合は、プレゼンテーションレイヤーの入力フォームハンドラーでこれをチェックする必要があります。