0

したがって、3つのモデルがあります。Cragには1つ以上のCragLocationがあり、各CragLocationにはLocationがあります。を使用して、岩山の特定のサブセットをクエリできます

public List<Crag> getCragsWithGridRef() {
        /**
         * we want to query select c.* from crag c join CragLocation cl on c.id
         * = cl.cragId join Location l on cl.locationId = l.id where
         * len(l.gridReference)>1
         */
        TypedQuery<Crag> query = 
                em.createQuery(
                        "SELECT c FROM Crag c JOIN c.CragLocations cl JOIN cl.location l where LENGTH(l.gridReference) > 1",
                        Crag.class);
        return query.getResultList();
    }

私の脳は基準クエリを処理できないため、私は主にこの方法でクエリを実行しています。私はそれらを見ているときに意味を解析するのに苦労しています。

それで、基準クエリを好むパフォーマンスまたは保守性（または他の）理由がありますか？もしそうなら、このクエリをどのように表現しますか？

4

1 に答える 1

3

いいえ、特にJPQLクエリを理解しやすく、したがって維持しやすく、基準クエリを理解し維持するのが難しいと考える場合は、JPQLクエリよりも基準クエリを優先する理由はありません（私は同意します）。

自動生成されたメタモデルを使用する場合、基準クエリを作成するのは困難ですが、一度作成すると、構文エラーがないことを確認できます。ただし、これは、クエリが想定どおりに機能することを意味するものではありません。したがって、いずれの場合も、クエリを単体テストする必要があります。クエリをカバーする単体テストがある場合は、最も読みやすく保守しやすいものを使用してください。基になるSQLクエリを生成する際にパフォーマンスの違いがあったとしても、実際にクエリを実行するコストと比較すると、この違いはごくわずかです。

Criteriaクエリは、次の2つの状況でのみ使用します（常にではありません）。

  1. クエリは、オプションの検索条件のセットから動的に構成されます
  2. 共通の部分を共有する多くの同様のクエリがあり、すべてのクエリでこの共通の部分を繰り返さないようにしたいと思います。基準を使用すると、共通部分を再利用可能な方法で配置できます。
于 2012-09-23T14:34:01.777 に答える