Mise en veille prolongée : Critères vs HQL

Question

Quels sont les avantages et les inconvénients de l'utilisation de Critères ou HQL? Les Critères de l'API est une belle méthode orientée objet pour exprimer des requêtes en mode veille prolongée, mais parfois Critères de Requêtes sont plus difficiles à construire que les requêtes HQL.

Quand utilisez-vous des Critères et quand HQL? Que préférez-vous dans lequel cas d'utilisation? Ou est-ce juste une question de goût?

Answer 1

Je préfère surtout les requêtes de critères pour les requêtes dynamiques. Par exemple, il est beaucoup plus facile d’ajouter une commande dynamiquement ou omettre certaines parties (par exemple les restrictions) selon certains paramètres.

En revanche j’utilise HQL pour les requêtes statiques et complexes, car il est beaucoup plus facile à comprendre/lecture HQL. En outre, HQL est un peu plus puissant, je pense, par exemple pour les types de jointure différent.

Answer 2

Il y a une différence en termes de performances entre les requêtes HQL et criteriaQuery, chaque fois que vous lancez une requête à l'aide de criteriaQuery, il crée un nouvel alias pour le nom de la table qui ne se reflète pas dans la dernière interrogé cache pour toute DB. Cela conduit à une surcharge de la compilation de la requête SQL générée, en prenant plus de temps à s'exécuter.

Concernant les stratégies de chargement [http://www.hibernate.org/315.html]

• Critères respecte la paresse paramètres de votre mappages et garantit que ce que vous voulez chargé est chargé. Cela signifie que l'un des Critères de la requête peut entraîner plusieurs SQL immédiate des instructions SELECT pour extraire les sous-graphe avec tous les non-lazy cartographié les associations et les collections. Si vous souhaitez modifier le "comment" et même le "quoi", utilisez la méthode setFetchMode() pour activer ou désactiver la jointure externe extraction pour une collection particulière ou d'une association. Les critères de requêtes aussi complètement égard, les stratégies de chargement (joindre vs sélectionnez vs sous-sélection).
• HQL respecte la paresse paramètres de votre mappages et garantit que ce que vous voulez chargé est chargé. Cela signifie une requête HQL peut entraîner plusieurs SQL immédiate des instructions SELECT pour extraire les sous-graphe avec tous les non-lazy cartographié les associations et les collections. Si vous souhaitez modifier le "comment" et même le "quoi", utiliser LEFT JOIN FETCH pour permettre extérieur-chargement par jointure ouverte pour une collection particulière ou nullable plusieurs-à-un ou un-à-un association, ou JOIN FETCH pour permettre inner join fetch pour un non nullable plusieurs-à-un ou un-à-un association. Des requêtes HQL ne respecte fetch="join", défini dans le document de mapping.

Answer 3

Critères est une API orientée objet, tout en HQL moyens de concaténation de chaîne. Cela signifie que tous les avantages de l'objet-orienté s'appliquent:

1. Toutes choses étant égales par ailleurs, l'OO version est un peu moins sujettes à l'erreur. Une vieille chaîne pourrait obtenir ajoutées dans la requête HQL, alors que seuls Critères valables objets peuvent en faire un des Critères de l'arbre. Effectivement, les Critères des classes sont plus limitées.
2. L'auto-complétion, l'OO est plus détectable (et donc plus facile à utiliser, du moins pour moi). Vous n'avez pas nécessairement besoin de vous souvenir des parties de la requête aller où; l'IDE peut vous aider à
3. Vous n'avez pas besoin de se rappeler les détails de la syntaxe (comme les symboles qui vont où). Tout ce que vous devez savoir, c'est comment faire pour l'appel de méthodes et de créer des objets.

Depuis HQL est très bien comme SQL (que la plupart des devs savent déjà très bien), alors ces "ne pas oublier" les arguments ne portent pas beaucoup de poids. Si HQL a été de plus en plus différents, alors ce serait plus importatnt.

Answer 4

J’utilise habituellement des critères quand je ne sais pas quels seront les entrées utilisées sur quels éléments de données. Comme sur un moteur de recherche où l’utilisateur peut entrer un des Articles de 1 à 50 et je ne sais pas ce qu’ils vont chercher des. Il est très facile de simplement ajouter plus aux critères que je passe par la vérification de ce que l’utilisateur cherche. Je pense qu’il serait un peu plus pénible à mettre une requête HQL dans cette circonstance. HQL est super bien quand je sais exactement ce que je veux.

Answer 5

HQL est beaucoup plus facile à lire, plus facile à déboguer à l’aide d’outils tels que le plugin Hibernate Eclipse et plus facile d’ouvrir une session. Les requêtes de critères sont mieux pour la construction des requêtes dynamiques où beaucoup du comportement est déterminé lors de l’exécution. Si vous ne savez pas SQL, je pourrais comprendre à l’aide de requêtes de critères, mais dans l’ensemble je préfère HQL si je sais ce que je veux initiaux.