アプリケーションテンプレートの考え方

アプリケーションテンプレートは、過去の実績からWEBアプリケーションの良きモデルとして定義されたものであり、開発プロジェクトの要件や特性に応じてカスタマイズすべき場合も存在します。しかし、一からアプリケーション構造を考えるのではなく、統合アプリケーションテンプレートをベースとして利用し、必要に応じて修正することをお勧めします。テンプレートとして品質が保証されたものであることを理解ください。 以下にテンプレートの考え方を説明します。

(1) オンライントランザクションのレスポンスを重視

特にアプリケーションサーバを立てる場合を想定し、トランザクション単位に業務ロジックはファサードで実現する。（１オンライントランザクションでWEBサーバ・APサーバ間のトランザクションは１つとする：細粒度の業務ロジックをネットワーク越しに何度も呼ばない）

(2) バリデーション（入力項目値の検証）はトランザクション（クリック）単位

WEBアプリケーションに限りませんが、1画面には多くの入力項目、操作が配置されます。１操作に期待される入力項目の検証範囲は必ずしも画面に配置された全入力項目が対象となるわけではありません。
.NETではポストバック（アプリケーション操作の多くは理論的に1画面の中で複数回実行されることを前提にした概念）を基本に置いているためか、1画面に配置される全ての入力項目がバリデーションの対象となっており、設計上の制約となっています。逆にいえば、.NETで用意されたバリデーションとは別に実装する必要があります。(実際、.NETではクリック単位に限定された項目をバリデーションする工夫を実装しています)
トランザクション単位にコントローラを用意し、config設定でバリデーション範囲を指定します。（Strutsをベースにする場合はStrutsのconfigに従うといった選択も可能）

(3) 画面遷移

画面遷移は必ずしもオンライントランザクションに固定ではありません。バリデーションエラーの場合は、通常、元画面にエラーメッセージを表示するため、画面遷移が発生しないことは理解いいただけると思います。
また、検索画面で検索結果が1件の場合、検索結果画面ではなく、当該情報の詳細表示画面に遷移させることもあります。
画面表示を担当するJSPの指定は、コントローラのconfig設定で業務ロジックの戻りステータスに応じて設定することで業務ロジックから分離します。（戻りステータスはファサードで管理：ファサードがビューを意識する：ファサードまでがコントローラの役割と考えます）

(4) 業務ロジックはDAOを通してデータ（DTO）を送受する

（データ格納場所はDBサーバだけとは限らない）

(5) SQLはDBIの中でのみ使用する

（SQLチューニングを横展開するときの検索を容易にする）