4

更新 II: OK、少し絞り込むことができました。

ソート機能とフィルタリング機能を備えたデータテーブルを含むページがあり、どちらもDBで行われます。つまり、私が使用する rich:datatable の組み込み機能は使用せず、DB に作業を任せます。

私はリクエストスコープのBeanを扱っています。セッション スコープの Bean だけに、インターフェイスの並べ替えとフィルタリングが含まれています。

各列のフィルタリングは、特定のセッション Bean フィールドにバインドされています。そのため、モデル値の更新フェーズで実際に更新されます。

ソートにはいくつかのロジックが必要だったので、特定のメソッドを呼び出して、セッション Bean に正しい値を設定しました。これは、Invoke Application フェーズで実行されます。

そのため、変更は、ページが実際にレンダリングされる Render Response フェーズで行われます。

問題は、ページ内の JSF データテーブルとデータスクローラーがbackingBean.getDataModel()、DB からデータを取得するdataModel.getRowCount()を呼び出し、(別のクエリを実行するメソッドを呼び出すために実装した)も要求値の適用フェーズ中に呼び出すことです。これら 2 つのクエリは、Render Response フェーズでも行われます。これは、すべての変更が行われる唯一のフェーズであり、クエリは正常に実行されます。

これは、フィルタリングまたはソートを実行した後にページを表示するために、2 倍の数のクエリが発生することを意味します。

必要なクエリのみを実行し、それ以上は実行せずに、並べ替えとフィルター処理を実行したいと考えています。

助言がありますか？

4

1 に答える 1

1

リクエスト値の適用フェーズでの getter 呼び出しは必須です。これは、JSF が最初に表示された入力値を認識して、最終的に検証を実行したり、必要に応じて次のフェーズで valuechangelisteners を呼び出したりできるようにする必要があるためです。また、いずれかの行でどのボタン/リンクが押されたか/クリックされたかを調べて、アクション呼び出しフェーズでどの Bean アクションを呼び出すかを知ることも必須です。

しかし、検証/値の変更をチェックする入力フィールドも、どの行にもボタン/リンクがない場合は、リクエスト値の適用段階でのクエリは完全に不要であると想像できます。

残念ながら、完全に無効にすることはできません。技術的には、データ Bean をセッション スコープに配置し、Bean のコンストラクターと Bean アクション メソッドでのみ高価な SQL クエリ (およびデータモデルの更新) を実行する唯一の手段です。構築（最初のビューの場合）およびBeanのアクションメソッド中（新しいソート/フィルター/その他のリクエスト中）。ただし、欠点は、データモデルの変更がエンドユーザーが同じセッションで開いているすべてのウィンドウ/タブに反映されることです。エンドユーザーのための経験。

preserveDataModelさて、トマホークは の属性のフレーバーでこれに対する優れた回避策を備えた最初のものでした<t:dataTable>。これは基本的にデータモデルをリクエスト固有のコンポーネントツリーに配置します（これはすでにセッションスコープまたは非表示の入力フィールドに保存されていますクライアント側では、faces-config でビュー ステートの保存場所をどのように構成したかによって異なります)。RichFaces にはそのような直接的な解決策はありませんが、<a4j:keepAlive>基本的には同じです。「全体」の Bean にのみ影響するため、データ Bean にデータモデル以外のものが含まれている場合は、リファクタリングを検討してください。セッション スコープの Bean であるかのように Bean を設計することに注意してください。

データモデルが大きくなった場合、これがサーバーのメモリに影響を与えると想像できますが、データモデルの表示可能な部分のみをメモリに保存する場合 (したがって、他のすべてを含むデータモデル全体ではない場合)、それほど害はありません。ページ）。1 つの HTTP リクエスト中に 2 つの SQL クエリを起動するコストを上回るかどうかを確認します。

お役に立てれば。

于 2010-03-03T20:11:07.147 に答える