エンタープライズ デザイン パターンは初めてです。私は、データ アクセス オブジェクトが入力を検証することを想定していないと言われました。他のレイヤーが検証を実行すると想定されている場合、そのレイヤーは、テーブル名などのデータベースの詳細をすべて知る必要はないでしょうか? カプセル化を破ることで、DAO を持つという目的が無効になるのではないでしょうか?
おそらく、DAOの責任についての私の理解はずれており、サービス層もデータベースの知識を持っていると思われますが、それは奇妙に思えます。現在、データ アクセス オブジェクトは CRUD 操作のみを実行しています。
注:私は通常のサーブレットを使用しており、MVC フレームワークや永続化フレームワークは使用していません。
データ アクセス オブジェクトの適切な実装では、crud 操作のみを実行する必要があります。データベースに存在する必要がある唯一の検証は、一意のインデックス、外部キー、チェック制約などの入力制約です。それ以外のすべては、DAO とインターフェイスするレイヤーによって処理される必要があります。このような制約は、テーブルを取得または更新する前に db サーバーが自動的に実行するように設定できます。それをDAOのロジックに入れる必要はありません。
通常の 3 層アプリケーションには、インターフェース層、ビジネス層、およびデータ層があります。多くの場合、データ層はデータベースを覆う非常に薄いカバーであり、varchar 列の文字列の長さを検証する場合がある以外は、通常は検証を行いません。ビジネス
検証 (ユーザー名に数字が含まれてい
ない、パスワードにスペースを使用できないなど) は、インターフェイス レイヤー (パフォーマンス上の理由から) とビジネス レイヤーの両方で行われます。どこかでサンプル Web アプリケーションを見つけた場合、うまくいけば、これをかなり明確に示しているはずです。