Quais são alguns dos exemplo do mundo real onde JPA2 Critérios API é mais preferível?

Question

Eu tenho tido um olhar JPA 2.0 Critérios de API, mas eu achei que fosse muito pesado, ao contrário do Hibernate Critérios.Há alguma boa razão para usar JPA 2.0 Critérios de API em vez de usar JPA-QL?Obrigado por seu aconselhar.

Answer 1

Como a API de critérios de hibernato, a API de critério JPA 2.0 é especialmente boa para criar consultas dinamicamente, para lidar com casos em que a estrutura da consulta varia dependendo das condições de tempo de execução.

Mas há mais. Embora seja mais detalhado do que a API de critérios de Hibernate, a API de critério JPA permite construir TypeAfe Consultas (se você usar a API do Metamodel). Abaixo de um exemplo:

EntityManager em = ...
QueryBuilder qb = em.getQueryBuilder();
CriteriaQuery<Person> c = qb.createQuery(Person.class);
Root<Person> p = c.from(Person.class);
Predicate condition = qb.gt(p.get(Person_.age), 20);
c.where(condition);
TypedQuery<Person> q = em.createQuery(c); 
List<Person> result = q.getResultList();

No snippet acima, o seguinte levantaria um erro de compilação, por exemplo:

Predicate condition = qb.gt(p.get(Person_.age, "xyz"));

Caso você se pergunte, Person_ é o Metamodel estática, instanciada e canônica correspondente ao original Person Classe de entidade (gerada por um processador de anotação). Ele fornece uma alternativa fortemente digitada a uma abordagem baseada em reflexão de tempo de execução:

Field field = Person.class.getField("age");

Prós:

• Tipo de segurança, verificação do tempo de compilação!
  • Proíbe a construção de consultas que são sintaticamente incorretas.
  • Pode aumentar um erro de compilação após uma refatoração.
  • Fornece suporte fora da caixa para conclusão automática
• Mais adequado para consultas dinâmicas.

Contras:

• Mais detalhado.
• Menos legível.

Sinto -me em geral mais confortável com o JPQL, mas o tipo de segurança da API de critérios é uma grande diferença com o JPQL (e também a API de critérios de hibernato).

Veja também

• Usando a API de critérios e API de metamodelo para criar consultas básicas para seguras de tipo
• Consultas dinâmicas e digitais no JPA 2.0
• Comparando JPQL, critérios baseados em cordas e consultas TypeAfe
• Uma API de consulta de critérios do TypeAfe para JPA

Respostas relacionadas

• Consulta dinâmica do JPA 2.0 usando API de critérios
• linguagem de consulta de hiberna ou usando critérios
• Hibernato: Critérios vs. HQL

Answer 2

A API do JPA 2.0 Criteria é a API baseada em objetos para construir consultas. Eu acho que pode jogar um bom trabalho quando você tem uma consulta dinâmica que pode se tornar mais legível do seguinte modo

cq.select(...)
  .where(...)
  .orderBy(...)
  .groupBy(...);

Mas ao usar estático Consulta prefere usar um externalizado, sustentável e legível Arquivo

<entity-mappings>
    ...
    <named-query name="ORDER">
       <query>
           <![CDATA[
               from
                   Order
           ]]>
       </query>
    </named-query>
    <named-query name="ORDER_WITH_LINE_ITEM">
       <query>
           <![CDATA[
               from
                   Order o
               inner join fetch 
                   o.lineItemList
           ]]>
       </query>
    </named-query>
    ...
</entity-mappings>

Se você tiver um aplicativo modularizado, use um arquivo XML para cada módulo da seguinte maneira

br
   com
       ar
           moduleA
               model
                   repository
                       moduleA.xml
           moduleB
               model
                   repository
                       moduleB.xml               
           moduleC
               model
                   repository
                       moduleC.xml

Então você define seu elemento de arquivo de mappinf

<mapping-file>br/com/ar/moduleA/model/repository/moduleA.xml</mapping-file>
<mapping-file>br/com/ar/moduleB/model/repository/moduleB.xml</mapping-file>
<mapping-file>br/com/ar/moduleC/model/repository/moduleC.xml</mapping-file>

Answer 3

JPA 2 Critérios podem ser usados em estaticamente tipada forma, se você gerar a entidade metamodelo.Ele é mais detalhado do que JPQL, mas é estaticamente tipada e suporte dinâmico de construção de consulta diretamente.

Os benefícios de um estaticamente tipada linguagem de consulta é que você pode pegar mais erros em tempo de compilação e IDE recursos como autocompletar pode ser bem utilizado.

Answer 4

Para mim, o exemplo do mundo real em que o JPA2 brilha quando você precisa criar uma consulta com base na entrada de um usuário. Não estou falando de um muito simples onde com um parâmetro. Quero dizer, quando você fez uma opção de pesquisa avançada em seu aplicativo. Um que requer junções quando um determinado parâmetro é preenchido. Você não o que concorde seu HQL ou SQL para incluir um grande conjunto de parâmetros, junções e funções extras. O SQL personalizado requer muitos testes para provar que funciona. Adicionar opções de pesquisa extras ao HQL e SQL requer muito retrabalho, enquanto isso pode ser mais simples no JPA.