私のJavaアプリケーションは、オブジェクトの永続化にJPAを使用しています。ビジネスドメインは非常に単純です（3つのクラスだけが永続的で、それぞれに3〜5個のプロパティがあります）。クエリも簡単です。問題は、JPQLとCriteriaAPIのどちらのアプローチを使用すべきかということです。
質問する
29288 次
2 に答える
85
これはすでにSOでカバーされていると確信していますが、既存の質問は見つかりませんでした。だから、これが質問に対する私の見解です：
- JPQLクエリは書き込み/読み取りが簡単だと思います。
- Criteria APIは、動的クエリを構築するのに適しています。
これは基本的にHibernateで見つかるものです：Criteriavs.HQL。
ただし、JPA 2.0 CriteriaAPIとHibernateのCriteriaAPIには、言及する価値のある大きな違いが1つあります。JPA2.0Criteria APIはタイプセーフAPIであるため、コンパイル時のチェック、コードの完了、リファクタリングのサポートなどが向上します。メリットがJPQLの使いやすさを上回っていることに気付かないでください。
要約すると、動的クエリ（多基準検索機能など）を除いて、JPQLを好みます。
関連する質問
その他のリソース
于 2010-10-04T20:17:53.847 に答える
10
私は以前に同様の質問に回答しましたが、コミュニティの利益のためにここに回答を再投稿します。以下の私の答えに対して、アプリケーションサーバーを使用していると仮定します。
Criteria APIは、SQLインジェクションを防止するタイプセーフな方法で動的SQLクエリを構築できるようにするために存在します。そうしないと、SQL文字列を連結することになり、エラーが発生しやすく、セキュリティリスクも発生します。つまり、SQLインジェクションです。CriteriaAPIを使用するのはこのときだけです。
クエリが基本的に同じままで、異なるパラメータのみを受け入れる必要がある場合は、注釈付き@NamedQueriesを使用する必要があります。これらのパラメータは、より単純で、プリコンパイルされ、セカンダリキャッシュ内にキャッシュされ、サーバーの起動時に検証される可能性があります。
これは基本的に、基準クエリとの経験則@NamedQueriesです。私の経験では、Criteria APIが必要になることはめったにありませんが、必要になることがまれな場合に備えて存在するのは良いことです。
お役に立てれば。
于 2016-01-30T20:20:17.427 に答える