私は、アプリケーション ロジックをサーブレットに保持し、JSP を可能な限りシンプルに保つことの大ファンです。この理由の 1 つは、優れた Web デザイナーであれば、HTML の知識を拡張して、いくつかの JSTL タグを組み込み、単純な反復やアクセス Bean などを実行できるようにする必要があるためです。また、より複雑な/ajax/js コンポーネントを背後に置いておきます。タグ ライブラリ (displayTag に似ていますが、独自のコンポーネント用です)。
ほとんどの場合、すべてうまくいきます。サーブレットは必要な SQL を実行し、JSP がアクセスできるように結果を Bean に格納します。問題があるのは、アクセスしたいレコードが設計によって指定されている場合です。
最も明確な例はホームページです。人目を引く効果的なものである必要があります。サイトの他の部分のように統一する必要はありません。ここには、特定の製品レコードなどを照会したい、1 回限りの、または「特別なケース」がたくさんあります。
設計者が本当に望んでいるのは、製品 ID で製品 Bean を取得して、通常どおりプロパティにアクセスできるようにする方法です。もちろん、すべての製品に対してクエリを実行する必要はありません。また、プレゼンテーションでクエリを実行する必要もありません。
私はここで不可能なことを尋ねていると確信しており、何かをあきらめなければならない. 私の質問は何ですか?
編集
JSP を呼び出す前にすべてのアプリケーション ロジックを完成させる必要があると考えるのは間違っていますか? 私は、サーブレットですべてのクエリ/計算/処理を行い、(かなり) ダム Bean を (非常に) ダム JSP に渡すことがベスト プラクティスと見なされているという印象を受けました。
クエリの実際の複雑さを別のクラス (カスタム タグまたは Bean) にカプセル化し、JSP がそれを呼び出すことができるメソッドがいくつかあります。これにより、JSP は単純になりますが (目標 1)、JSP はまだクエリを「トリガー」しています。プロセスのかなり遅い段階です。
- 私はこれを完全に間違っていましたか?これを行うのは問題ありません。
- 一般的なルールですが、この場合はこれを行っても問題ありません。
- 問題が発生する可能性がありますか?
編集 - 例
この例が役立つことを願っています:
ホームページは、カテゴリ/検索ページのような「テンプレート」ではありません。たとえば、マーケティング画像やいくつかの特定の製品画像とうまく機能するようにカスタム設計されています. ただし、動的に取得する必要がある 2 つの製品に関する情報 (名前、および重要な価格) は、データベースと同期したままです。
設計者がそれらを変更/削除/追加したい場合、サーブレットはこれらがどの製品になるかを知ることができません.