完璧な世界では、プレゼンテーションや永続化レイヤーではなく、ビジネスロジック レイヤーで入力の検証(検証) を行います。実際には、どこにでも配置できます (または配置したい)。
簡単なサンプルを作成してみましょう ( JSF や ZK などのフレームワークを使用するWeb アプリケーション): 特定の入力フィールドは、0001 から 0500 までの 4 桁を受け入れます。
これを行うには、Web フレームワークの制約機能を使用できます。ユーザーにとって便利で、追加のサーバー負荷はありません。
ビジネス層 (java-ejb など) で実行できます。同じ ejb を使用するすべてのアプリケーションが同じ検証を使用するため、簡単です。評価後にユーザーにエラーを返す必要があるため、最終的には良くありません。サーバーとの往復が必要です。
誰かが (永続層を介して) 数字以外の値または 4 桁を超える値を入力した場合、DB が失敗することに (部分的に) 依存する可能性があります。醜い。
再開: 1. と 2. で (冗長に) 実行します (ユーザーにとって使いやすく、すべてのアプリケーションで一貫性のあるものにします)。(さらに DB col の長さは 4 になります)
質問: この検証をどのように文書化しますか? テキスト ドキュメントまたは UML ダイアグラム ? ある意味で、最大 3 つの場所にビジネス ロジックがあります。複雑なシステムでは、これを追跡して理解することはほぼ不可能です。
上記のサンプルの実際のシナリオ: 4 桁から 5 桁に変更する必要があります。ドキュメントがなければ、変更が必要な場所を探す必要があります。
あなたは何を経験しますか？このためのヒントやツールはありますか?
乾杯
スヴェン