5 Réponses :
Utilisez ensuite le modèle de métadonnées JPA-2.0. http://docs.jboss.org/ibernate/jpamodelgen/ 1.0 / Référence / EN-US / HTML_SINGLE /
L'utilisation du métamodel ne réduit pas la quantité de code tout cela beaucoup, mais améliore certainement la clarté et ajoute de plus en plus de sécurité.
Il semble qu'il n'ya aucun moyen de réduire la quantité de code. Je suppose que quelque chose devait être sacrifié pour gagner la sécurité de type.
Je cherchais quelque chose comme ça, vous pourriez jeter un coup d'œil à QueryDSL ( LGPL licencié) qui peut avoir une JPA comme backend.
Je lis toujours dans celui-ci, mais de leurs exemples, il a l'air assez propre. P>
HQLQuery q = new HibernateQuery(session);
QCat cat = new QCat("cat"); // query type
List<Cat> cats = q.from(cat).where(cat.name.between("A", "B")).list(cat);
Bien que ce cadre ne soit pas lié aux critères API et se tient seuls, cela vaut certainement la peine d'être examinée. Merci pour la mention de cela, je vais l'explorer quand j'en aurai la chance!
Juste une correction mineure, QueryDsl est licencié LGPL, et non sous licence GPL.
QUERYDSL.com Il semble également que la licence a été modifiée par Apache License, version 2.0.
En JPA 2.1, il sera probablement possible de mélanger JPQL et critères. Avec une telle approche, vous pouvez définir une requête de base avec JPQL, puis utiliser l'API de critères pour ajouter de manière dynamique de petites pièces.
i Figure L'API sera moins verbeuse alors, puisque vous n'avez qu'à utiliser de petites parties de celui-ci.
Je ne sais pas si cela serait logique de mélanger JPQL avec des requêtes de critères. Y compris JPQL irait à l'encontre de l'idée principale derrière les critères API - de fournir une sécurité de type de compilation.
C'est un compromis bien sûr. C'est tout comme en utilisant el et dans certains cas des annotations. Vous négociez dans la sécurité de la compilation pour la flexibilité et la moins de code Verbose. Quoi qu'il en soit, le lot des gens pensent que cela fait des sens comme Linda (Spec Dirige) considère sérieusement cela pour JPA 2.1. Le choix est alors le vôtre: pure JPQL, JPQL mélangée à des critères et même dans les critères que vous avez les variantes de type-coffre-fort et sans sécurité. Utilisez ce qui fonctionne pour vous.
méthode obsolète, ce post, mais je veux ajouter ce que j'ai récemment construit pour des requêtes simples Vous pouvez l'utiliser comme ceci À la fin, j'ai arrêté cela. Principalement parce que j'ai vu que je n'avais que deux questions et je devrais étendre la DSL pour obtenir les caractéristiques de la requête requises, telles que En outre, je le trouve laid de toujours appeler BTW: Oubliez les noms, c'était un prototype, rien de plus.
QueryBuilder.CurrentDate () et similaire.
où en correspondant à un plus sqlly et . Quoi qu'il en soit, si quelqu'un est intéressé par une API de requête très simple, cela vaut toujours la peine d'essayer.
Cette situation peut être facilement abordée à l'aide de la stratégie. Il suffit de créer une méthode privée que la méthode doit prendre un paramètre (une interface) de type Say, WhherecLauseBuilder, la méthode privée obtiendra sa partie variable (où la clause) de ce paramètre via un appel de méthode qui transmet le critère et la requête. Toutes les méthodes publiques appelleront simplement la méthode privée avec un whausebuilder spécifique qui renvoie le prédicat requis où la clause.