29

Criteria APINamedQueryの間の決定のためのヒューリスティック/ベストプラクティス/ルールセットはありますか?

これまでの私の考え:
名前付きクエリは一般的に読みやすくなっています。基準クエリはより柔軟です。
どちらもプリコンパイルされています。私は、名前付きクエリをできるだけ長く使用してから、基準に変更することに依存する傾向があります。

しかし、基準APIを使用してクエリを「柔軟化」したいという衝動は、最適ではない設計(つまり関心の分離)のヒントになるのではないでしょうか。

ありがとうございました

4

5 に答える 5

36

名前付きクエリの方が最適です(一度解析/準備されます)。基準クエリは動的です(EclipseLinkなどの一部のJPAプロバイダーは基準準備キャッシュを維持していますが、プリコンパイルされていません)。

基準は動的クエリにのみ使用します。

于 2011-09-07T13:17:12.217 に答える
10

基準クエリは、たとえば、変数や複数の検索基準に基づいてクエリを動的に生成する必要がある場合に適しています。

静的クエリの場合、JPQLの方がはるかに読みやすく、条件クエリよりもJPQLを使用する方が好きです。安全性がいくらか失われる可能性がありますが、単体テストにより自信が持てるようになります。

于 2011-09-07T12:47:02.257 に答える
4

もう1つの視点は、基準クエリはそれほど読みやすくはありませんが、タイプセーフであるため、コンパイル時のタイプチェックを提供するということです。多くのエンティティと多くのクエリが存在するプロジェクトでデータベースを変更する場合、コンパイル時に、変更が原因でどのクエリが失敗したかを確認すると非常に役立ちます。

一方で、それがJPQLのシンプルさよりも有益かどうかはわかりません

于 2012-07-31T08:13:09.597 に答える
3

私は実際にHibernate(4.3.0-SNAPSHOT)ソースとEclipseLink(2.5.0-SNAPSHOT)ソースを調べ、それぞれのJPA実装を調べました。

EclipseLinkは、あなたが説明する方法では明らかにスレッドセーフではありません。具体的には、結合を繰り返し再計算しようとします。

Hibernateの実装は私にはスレッドセーフに見えます。100%確信はありませんが、確かにそうです。指定されていないため、将来的には真実であるとは限りません。

しかし、私はあなたに警告します、私はあなたが多くを得るつもりはないと思います。私が見ていることから、クエリのコンパイルの多くは実際には「createQuery」フェーズで行われるため、結果をキャッシュすることすらできません。

于 2014-03-16T03:37:37.397 に答える
2

JPAは、@ NamedQueryおよび@NamedQueriesアノテーションを使用して、名前付きクエリとして静的クエリを構築する方法も提供します。可能であれば、動的クエリよりも名前付きクエリを優先することは、JPAでは良い習慣であると考えられています。http://www.objectdb.com/java/jpa/query/apiから

于 2014-06-06T16:36:52.197 に答える