JPA e Hibernate - Critérios vs. JPQL ou HQL

Quais são os prós e os contras do uso de Critérios ou HQL ? A API de critérios é uma boa maneira orientada a objetos para expressar consultas no Hibernate, mas às vezes as consultas de critérios são mais difíceis de entender / criar do que o HQL.

Quando você usa Critérios e quando HQL? O que você prefere em quais casos de uso? Ou é apenas uma questão de gosto?

Eu prefiro consultas de critério para consultas dinâmicas. Por exemplo, é muito mais fácil adicionar alguns pedidos dinamicamente ou deixar algumas peças (por exemplo, restrições) de fora, dependendo de algum parâmetro.

Por outro lado, estou usando o HQL para consultas estáticas e complexas, porque é muito mais fácil entender / ler o HQL. Além disso, acho que o HQL é um pouco mais poderoso, por exemplo, para diferentes tipos de junção.

Há uma diferença em termos de desempenho entre HQL e criterQuery, sempre que você dispara uma consulta usando o critérioQuery, ele cria um novo alias para o nome da tabela que não reflete no último cache consultado para nenhum banco de dados. Isso leva a uma sobrecarga de compilação do SQL gerado, levando mais tempo para ser executado.

Sobre estratégias de busca [http://www.hibernate.org/315.html]

• Os critérios respeitam as configurações de preguiça nos seus mapeamentos e garantem que o que você deseja carregar seja carregado. Isso significa que uma consulta de Critérios pode resultar em várias instruções SELECT imediatas do SQL para buscar o subgráfico com todas as associações e coleções mapeadas não preguiçosas. Se você deseja alterar o "como" e até o "o quê", use setFetchMode () para ativar ou desativar a busca de junção externa para uma coleção ou associação específica. As consultas de critério também respeitam completamente a estratégia de busca (junção x seleção x subseleção).
• O HQL respeita as configurações de preguiça nos seus mapeamentos e garante que o que você deseja carregar seja carregado. Isso significa que uma consulta HQL pode resultar em várias instruções SELECT imediatas do SQL para buscar o subgráfico com todas as associações e coleções mapeadas não preguiçosas. Se você quiser alterar o "como" e até o "o quê", use LEFT JOIN FETCH para ativar a busca de junção externa para uma coleção específica ou associação anulável de muitos para um ou um para um ou um JOIN FETCH para ativar busca de junção interna para uma associação muitos-para-um ou um-para-um não-anulável. As consultas HQL não respeitam nenhuma busca = "associação" definida no documento de mapeamento.

Critérios é uma API orientada a objetos, enquanto HQL significa concatenação de cadeias. Isso significa que todos os benefícios da orientação a objetos se aplicam:

1. Tudo o resto é igual, a versão OO é um pouco menos propensa a erros. Qualquer cadeia antiga pode ser anexada à consulta HQL, enquanto apenas objetos Criteria válidos podem transformá-la em uma árvore de Critérios. Efetivamente, as classes de Critérios são mais restritas.
2. Com o preenchimento automático, o OO é mais detectável (e, portanto, mais fácil de usar, pelo menos para mim). Você não precisa necessariamente lembrar quais partes da consulta vão para onde; o IDE pode ajudá-lo
3. Você também não precisa se lembrar dos detalhes da sintaxe (como quais símbolos vão para onde). Tudo que você precisa saber é como chamar métodos e criar objetos.

Como o HQL é muito parecido com o SQL (que a maioria dos desenvolvedores já conhece muito bem), esses argumentos "não precisam se lembrar" não têm tanto peso. Se o HQL fosse mais diferente, isso seria mais importante.

Normalmente, uso Critérios quando não sei quais serão as entradas em quais dados. Como em um formulário de pesquisa onde o usuário pode inserir de 1 a 50 itens e não sei o que ele estará procurando. É muito fácil anexar mais aos critérios à medida que passo verificando o que o usuário está procurando. Eu acho que seria um pouco mais problemático colocar uma consulta HQL nessa circunstância. HQL é ótimo quando eu sei exatamente o que eu quero.

O HQL é muito mais fácil de ler, mais fácil de depurar usando ferramentas como o plug-in Eclipse Hibernate e mais fácil de registrar. As consultas de critério são melhores para criar consultas dinâmicas em que muito do comportamento é determinado em tempo de execução. Se você não conhece SQL, eu poderia entender usando consultas de Critérios, mas no geral prefiro HQL se souber o que quero antecipadamente.

Os critérios são a única maneira de especificar pesquisas de chave natural que aproveitam a otimização especial no cache de consulta de segundo nível. O HQL não tem como especificar a dica necessária.

Você pode encontrar mais algumas informações aqui:

• http://tech.puredanger.com/2009/07/10/hibernate-query-cache/

Critérios A API é um dos bons conceitos do Hibernate. de acordo com o meu ponto de vista, esses são os poucos pontos pelos quais podemos fazer a diferença entre HQL e Critérios API

1. O HQL é executar operações de seleção e não seleção nos dados, mas Critérios é apenas para selecionar os dados, não podemos executar operações de não seleção usando critérios.
2. HQL é adequado para executar Consultas Estáticas, enquanto Critérios é adequado para executar Consultas Dinâmicas
3. O HQL não suporta o conceito de paginação , mas podemos obter a paginação com Critérios.
4. Os critérios costumavam levar mais tempo para serem executados que o HQL.
5. Com os Critérios, estamos seguros com o SQL Injection devido à sua geração dinâmica de consultas, mas no HQL, como suas consultas são fixas ou parametrizadas, não há segurança do SQL Injection

Para usar o melhor dos dois mundos, a expressividade e concisão do HQL e a natureza dinâmica dos Critérios consideram o uso do Querydsl .

Querydsl suporta JPA / Hibernate, JDO, SQL e Coleções.

Eu sou o mantenedor do Querydsl, então essa resposta é tendenciosa.

Para mim, os critérios são bastante fáceis de entender e fazer consultas dinâmicas. Mas a falha que eu digo até agora é que ele carrega todas as relações etc, porque temos apenas três tipos de FetchModes, isto é, Select, Proxy e Default e, em todos esses casos, carrega muitos (pode ser que eu esteja errado, se for o caso) estou fora :))

A segunda questão com os Critérios é que ele carrega o objeto completo, ou seja, se eu quiser carregar o EmpName de um funcionário, ele não cria esse instante, ele cria o objeto Employee completo e posso obter o EmpName por causa disso, ele realmente funciona mal em relatórios . onde o HQL apenas carrega (não carrega associação / relações) o que você deseja, para aumentar o desempenho muitas vezes.

Um recurso dos Critérios é que ele protegerá você do SQL Injection por causa de sua geração dinâmica de consultas, onde, no HQL, suas consultas são fixas ou parametrizadas, portanto, não são seguras do SQL Injection.

Além disso, se você escrever HQL em seus arquivos aspx.cs, estará fortemente associado ao seu DAL.

No geral, minha conclusão é que existem lugares em que você não pode viver sem o HQL como relatórios, portanto, use-os, caso contrário, os critérios são mais fáceis de gerenciar.

API de critérios

A API de critérios é mais adequada para consultas geradas dinamicamente. Portanto, se você deseja adicionar filtros da cláusula WHERE, cláusulas JOIN ou variar a cláusula ORDER BY ou as colunas de projeção, a API Criteria pode ajudá-lo a gerar a consulta dinamicamente de uma maneira que também evite ataques de injeção SQL .

Por outro lado, as consultas de Critérios são menos expressivas e podem até levar a consultas SQL muito complicadas e ineficientes, conforme explicado neste artigo .

JPQL e HQL

JPQL é a linguagem de consulta de entidade padrão do JPA, enquanto o HQL estende o JPQL e adiciona alguns recursos específicos do Hibernate.

JPQL e HQL são muito expressivos e se assemelham a SQL. Diferentemente da Criteria API, o JPQL e o HQL facilitam a previsão da consulta SQL subjacente gerada pelo provedor JPA. Também é muito mais fácil revisar as consultas HQL de uma pessoa do que as de critério.

Vale a pena notar que selecionar entidades com JPQL ou API de critérios faz sentido se você precisar modificá-las. Caso contrário, uma projeção DTO é uma escolha muito melhor.

Conclusão

Se você não precisar alterar a estrutura de consulta da entidade, use JPQL ou HQL. Se você precisar alterar os critérios de filtragem ou classificação ou alterar a projeção, use a API de critérios.

No entanto, apenas porque você está usando JPA ou Hibernate, isso não significa que você não deve usar SQL nativo. As consultas SQL são muito úteis e a API JPQL e Criteria não substitui o SQL. Confira este artigo para obter mais detalhes sobre este tópico.

Para mim, a maior vitória em Critérios é a API de Exemplo, onde você pode passar um objeto e o hibernate criará uma consulta com base nessas propriedades do objeto.

Além disso, a API de critérios tem suas peculiaridades (acredito que a equipe de hibernação está reformulando a API), como:

• um critério.createAlias ​​("obj") força uma junção interna em vez de uma possível junção externa
• você não pode criar o mesmo alias duas vezes
• algumas cláusulas sql não têm contrapartida de critérios simples (como uma subseleção)
• etc.

Costumo usar o HQL quando quero consultas semelhantes ao sql (excluir de Usuários em que status = 'bloqueado') e costumo usar critérios quando não quero usar o acréscimo de cadeias.

Outra vantagem do HQL é que você pode definir todas as suas consultas com antecedência e até externalizá-las para um arquivo ou mais.

A API de critério fornece um recurso distinto que nem o SQL nem o HQL fornecem. ie permite a verificação do tempo de compilação de uma consulta.

Usamos principalmente Critérios em nosso aplicativo no início, mas depois ele foi substituído pelo HQL devido a problemas de desempenho.
Principalmente, estamos usando consultas muito complexas com várias junções, o que leva a várias consultas nos Critérios, mas é muito otimizado no HQL.
O caso é que usamos apenas várias propriedades em objetos específicos e não objetos completos. Com Critérios, o problema também era concatenação de cadeias.
Digamos que, se você precisar exibir o nome e o sobrenome do usuário no HQL, é bastante fácil, (name || ' ' || surname)mas no Crteria isso não é possível.
Para superar isso, usamos o ResultTransormers, onde havia métodos em que essa concatenação foi implementada para obter o resultado necessário.
Hoje, usamos principalmente o HQL assim:

String hql = "select " +
            "c.uuid as uuid," +
            "c.name as name," +
            "c.objective as objective," +
            "c.startDate as startDate," +
            "c.endDate as endDate," +
            "c.description as description," +
            "s.status as status," +
            "t.type as type " +
            "from " + Campaign.class.getName() + " c " +
            "left join c.type t " +
            "left join c.status s";

Query query =  hibernateTemplate.getSessionFactory().getCurrentSession().getSession(EntityMode.MAP).createQuery(hql);
query.setResultTransformer(Transformers.ALIAS_TO_ENTITY_MAP);
return query.list();

portanto, no nosso caso, os registros retornados são mapas das propriedades necessárias.

• HQL é executar operações de seleção e não seleção nos dados, mas Critérios são apenas para selecionar os dados, não podemos executar operações de não seleção usando critérios
• HQL é adequado para executar Consultas Estáticas, enquanto Critérios é adequado para executar Consultas Dinâmicas
• O HQL não suporta o conceito de paginação, mas podemos alcançar a paginação com Critérios
• Os critérios costumavam levar mais tempo para executar que o HQL
• Com os Critérios, estamos seguros com o SQL Injection devido à sua geração dinâmica de consultas, mas no HQL, como suas consultas são fixas ou parametrizadas, não há segurança do SQL Injection.

fonte

Consulta de critérios para dinamicamente podemos construir consulta com base em nossas entradas .. No caso de consulta Hql é a consulta estática, uma vez que construímos, não podemos alterar a estrutura da consulta.

Não quero chutar um cavalo morto aqui, mas é importante mencionar que as consultas de critérios agora estão obsoletas. Use HQL.

Também prefiro Consultas de critério para consultas dinâmicas. Mas eu prefiro o hql para consultas de exclusão, por exemplo, se excluir todos os registros da tabela filho para o ID pai 'xyz', é facilmente alcançado pelo HQL, mas, para os critérios da API, primeiro devemos disparar n número de consultas de exclusão onde n é o número de filhos registros de tabela.

A maioria das respostas aqui são enganosas e mencionam que Criteria Queriessão mais lentas que HQL, o que na verdade não é o caso.

Se você se aprofundar e executar alguns testes, verá que as Consultas de Critérios têm um desempenho muito melhor que o HQL comum .

E também com a Consulta de Critérios, você obtém o controle Orientado a Objetos, que não existe no HQL .

Para mais informações, leia esta resposta aqui .

Existe outro caminho. Acabei criando um analisador HQL baseado na sintaxe original do hibernate, para analisar primeiro o HQL, para injetar dinamicamente parâmetros dinâmicos ou adicionar automaticamente alguns filtros comuns para as consultas HQL. Funciona muito bem!

Este post é bastante antigo. A maioria das respostas fala sobre os critérios do Hibernate, não sobre os critérios da JPA. O JPA 2.1 adicionou CriteriaDelete / CriteriaUpdate e EntityGraph que controla o que exatamente buscar. A API de critérios é melhor, pois Java é OO. É por isso que o JPA é criado. Quando o JPQL é compilado, ele será traduzido para a árvore AST (modelo OO) antes de traduzido para o SQL.

O HQL pode causar problemas de segurança , como injeção de SQL.