0

私は現在、さまざまな分野のさまざまな検索ページを持つ Hibernate に支えられた Java ベースの Web アプリケーション (JSF) を使用しています。

検索ページには、ユーザーが興味のある検索フィールドをカスタマイズできる検索フィールド セクションが含まれています。 、コンマ区切り値など)。検索フィールドに入力する必要はなく、無視されます。他の検索フィールドには、この検索フィールドが機能するために値を持たせるために別の検索フィールドが必要な場合があります。

現在、そのエリアに固有のカスタム検索オブジェクトをエリアごとに使用しており、ハードコーディングされた getter および setter 検索フィールドがあります。

public interface Search {
  SearchFieldType getSearchPropertyOne();
  void setSearchPropertyOne(SearchFieldType searchPropertyOne);

  AnotherSearchFieldType getSearchPropertyTwo();
  void setSearchPropertyTwo(AnotherSearchFieldType searchPropertyTwo);

  ...
}

この例では、SearchFieldType と AnotherSearchFieldType は、それぞれ検索タイプ (Starts with、Contains など) または (Greater Than、Equals、Less Than など) と検索値を持つ TextSearchField または NumericSearchField のような異なる検索タイプを表します。空のままにすることも入力することもできます (検索フィールドを無視するため)。

この検索オブジェクトを使用して Criteria オブジェクトを準備します

検索結果セクションは、ユーザーが関心のある結果オブジェクトの列のみを含むようにカスタマイズすることもできるテーブルです。ほとんどの列は、昇順または降順で並べ替えることができます。

結果ごとに Result オブジェクトに結果を返します。これは、表示できる列もハードコードします。このテーブルは hibernate アノテーションに支えられていますが、他の hibernate に支えられたオブジェクトが遅延結合データを最小限に抑えるのではなく、フラット データを使用しようとしています。

@Entity(table = "result_view")
public interface Result {
  @Column(name = "result_field_one")
  Long getResultFieldOne();
  void setResultFieldOne(Long resultFieldOne);

  @Column(name = "result_field_two")
  String getResultFieldTwo();
  void setResultFieldTwo(String resultFieldTwo);

  ...
}

検索ページは、考えられるすべての結果に必要なすべてのテーブルへの結合を処理するデータベースのビューによって支えられています。このビューはかなり大規模になり、30 以上の検索フィールド オプションと 30 の異なる列を表示できるため、ユーザーが 1 つのフィールドのみを検索していくつかの列を表示したい場合でも、すべての検索でパフォーマンスが大幅に低下します。これはすべて 1 つのビューに支えられています。

これに加えて、ユーザーはページに追加したい新しい検索フィールドと列を常にリクエストします。これらの変更を行うには、検索オブジェクトと結果オブジェクト、およびバッキング ビューを変更する必要があります。

私たちはこの問題を調査し、これに代わるものを見つけようとしています。言及されたアプローチの 1 つは、結果テーブルで検索または表示されるフィールドに基づいて動的に選択するさまざまなビューを作成することでした。さまざまなビューがさまざまな列に結合される可能性があり、特定の検索に必要なビューを選択します。

私はその問題を別の方法で考えようとしています。ビューを使用せず、代わりに、要求された検索フィールドと結果列に基づいて、必要なテーブルを動的に結合する方がよいと思います。また、検索オブジェクトと結果オブジェクトには、ハードコーディングされたゲッター/セッターを含めるべきではなく、代わりに検索フィールドのコレクションと結果列のコレクション (またはマップ) にする必要があると思います。私はまだ自分の考えを完全に具体化しているわけではありません。

休止状態は、この問題に対する有効な解決策でしょうか? 結果列が異なる可能性があるため、休止状態の基準で使用される Result オブジェクトを作成する必要はありません。検索フィールドと結果列の両方で、テーブルの結合が必要になる場合があります。

問題の解決に役立つ可能性のある使用できるフレームワークはありますか? 私は何かを探していましたが、私が見つけた最も近いものは SqlBuilder です。

他の誰かが同様の問題を動的に解決しましたか?

解決策がすでに存在する場合、車輪の再発明はしたくありません。

これがテキストの壁になってしまったことをお詫びします。これは私の最初のスタックオーバーフローの投稿であり、問​​題を完全に定義したことを確認したかった.

ご回答ありがとうございます。

4

1 に答える 1

0

私は問題を完全には理解していません。しかし、JPA Criteria API は非常に柔軟性があり、ユーザーが送信したフィルタリング条件に基づいてクエリを作成するために使用できます。

于 2012-05-03T01:09:51.370 に答える