Utilisation de DTO pour alléger les appels?

Bonjour,

Je suis passé au EJB3, c'est super plus d'xml, les annotations et ... les entity qui sont maintenant des POJO, donc plus besoin de créer des DTO.

Par contre imaginons que je veuille lister par exemple des personnes ... mais juste leur nom, prénom et âge.
J'appelle mon sessionBean qui me récupère une liste d'entity "personne" (Avec un requête ejbq dans le genre "SELECT o from Personne o"). Pas de DTO donc je renvois cette liste directement à ma servlet pour ensuite les afficher dans ma JSP.
Mais voilà au lieu de récupérer une liste de 3 champs("Nom","Prénom","age"); j'ai récupéré toutes les infos de la table personne. Ça fait quand même beaucoup de ressources utilisées pour pas grand chose non ?

Donc ma question est "quel design pattern adopter pour vraiment récupérer les données dont j'ai besoin quand j'en ai besoin ? "

- Faire plutot des requetes "SELECT o.x , o.y, o.z from Table o" et construire le DTO correspondant afin de le renvoyer a ma "Vue".
- Mettre tous le champs en LAZY et fetcher qd j'en ai besoin(je ne suis même pas certain que ce soit possible)
- Utiliser une subtilité des EJB3 qui m'aurait échapée ?
- ...

Merci pour vos idées,réponses !

Tu peux très bien faire ca :

Code:

---

SELECT o.nom,o.prenom,... from Personne o)

---

et il te renverra une collection que tu devras recuperer en List<Object[]>, et caster.

Citation:

---

Envoyé par Lethal

- Utiliser une subtilité des EJB3 qui m'aurait échapée ?

---

En l'occurrence une subtilité de JPA 2.0, Constructor Expressions. En gros, tu crées un DTO avec un constructeur adéquat, et tu utilises l'opérateur NEW dans la requête SELECT.
Exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

package myapp;   public class PersonneDTO { private String nom, prenom; private int age;   public PersonneDTO(String nom, String prenom, int age) { this.nom = nom; this.prenom = prenom; this.age = age; } ... // getters }

---

...
Puis dans l'EJB, ou le DAO:

Code:

---

1 2 3 4

String query = "SELECT NEW myapp.PersonneDTO(p.nom, p.prenom, p.age) FROM Personne p"   List<PersonneDTO> result = entityManager.createQuery(query, PersonneDTO.class).getResultList();

---

Nikel, c'est exactement le genre de "subtilité" que je cherchais !

Poussons un peu plus loin. Ce qui me simplifie aussi la vie dans les ejb c'est les jointures.
Avec une requete EJBQL habituelle si je veux récupérer la liste des publications d'une personne par exemple ( dans mon entity Personne :

Code:

---

1 2	@OneToMany(cascade={CascadeType.REFRESH},mappedBy = "personne") private List<Publication> publicationList;

---

qui est en LAZY par défaut) je n'ai qu'a rajouter left join fetch p.listPublication à ma requete (et un distinct au début) et je récupère le tout.

par contre avec la requête

Code:

---

String query = "SELECT NEW myapp.PersonneDTO(p.nom, p.prenom, p.age,lp) FROM Personne p left join p.publicationList lp"

---

Il tente d'appeller le constructeur Personne(String,String,Publication) et pas Personne(String,String,List<Publication>). Ce qui est normal car c'est le même comportement qu'avec un tableau d'objet...

Vous avez une idée de ce que serait le meilleur moyen pour me retrouver au final avec une Liste de PersonneDTO comportant 2 String et une Liste de PublicationDTO ?

Je ne connais pas encore la syntaxe avec NEW mais pour ta question il te suffirait de faire :

Code:

---

String query = "SELECT p.nom,p.prenom,p.age ,lp FROM Personne p left join p.publicationList lp"

---

Tout simplement.

Citation:

---

Envoyé par DevServlet

Je ne connais pas encore la syntaxe avec NEW mais pour ta question il te suffirait de faire :

Code:

---

String query = "SELECT p.nom,p.prenom,p.age ,lp FROM Personne p left join p.publicationList lp"

---

Tout simplement.

---

Oui, comme dit précédement mais justement le problème est que si je fais ça et que j'ai par exemple 2 personnes qui on chacune 3 publications j'aurai

Code:

---

1 2 3 4 5 6

Nom1 , Prénom1, Age1 , publication1 Nom1 , Prénom1, Age1 , publication2 Nom1 , Prénom1, Age1 , publication3 Nom2 , Prénom2, Age2 , publication4 Nom2 , Prénom2, Age2 , publication5 Nom2 , Prénom2, Age2 , publication6

---

Puis je ne veux pas récupérer un tableaux d'objet de ma query mais bien une liste de DTO comme dit précédemment.

Mais le problème est qu'au lieu de récupérer une liste de publication dans mon constructeur de DTO personne, je récupère 1 publication. j'aimerais le meme comportement qu'avec les entitiy donc récupérer 2personnesDTO qui possèdent une Liste de publications.

Si il y a une méthode propre tant mieux sinon je ferai un truc du genre:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Query lo_query = em.createQuery("SELECT NEW dto.PersonneDTO(p.id,p.nom,p.prenom,p.age,pl.libelle) from Personne p left join p.publicationList pl"); List<PersonneDTO> lo_listP = lo_query.getResultList(); PersonneDTO lo_lastP = new PersonneDTO(0L,"foo","foo",25L,"foo"); PersonneDTO lo_curP;     for(int i = 0 ; i < lo_listP.size() ; i++) { lo_curP = lo_listP.get(i); if(lo_curP.getId() == lo_lastP.getId()) { lo_lastP.getPublicationList().addAll(lo_curQ.getPublicationList()); lo_listP.remove(i); i--; } lo_lastP = lo_curP; }   return lo_listP;

---

avec

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

public class PersonneDTO implements Serializable { private Long id; private String nom; private String prenom; private Long age; private List<PublicationDTO> publicationList;   public QuestionDTO(Long id,String nom,String prenom,Long age,String publicationlibelle) { publicationList = new ArrayList<PublicationDTO>(); this.nom = nom; this.prenom = prenom; this.age = age this.publicationList.add(new PublicationDTO(publicationLibelle)); this.id = id; }   .....   }

---

J'ai un peu de mal à te suivre, j'ai pas très bien compris ta petite boucle, mais dis moi,qu'est ce qui te gene dans la récupération d'une collection pareille :

Code:

---

1 2 3 4 5 6

Nom1 , Prénom1, Age1 , publication1 Nom1 , Prénom1, Age1 , publication2 Nom1 , Prénom1, Age1 , publication3 Nom2 , Prénom2, Age2 , publication4 Nom2 , Prénom2, Age2 , publication5 Nom2 , Prénom2, Age2 , publication6

---

Je n'ai pas encore utilisé le NEW comme je disais, mais si le but des objets DTO c'est constituer des POJO distincts dans un même objet, c'est pas bête. Mais pour ton pb, peux tu repreciser la question, je pense qu'il est faisable directement en JPQL.
En passant, tes variables JAVA ne sont pas bien nommés, jamais de lettre "_" dans les variables. fais un tour sur les best pratices JAVA.

Tout d'abord pour la nomenclature je sais, mais j'ai pas le choix! Mais apparament on est pas les seuls :

Citation:

---

Envoyé par http://www.loribel.com/java/normes/nommage.html

De plus, d'une manière générale :

* N'utiliser que les lettres [a-z] et [A-Z] et [0-9] : Ne pas utiliser de tiret '-', d'underscore '_', ou d'autres caractères ($, *, accents, ...).

A débattre :

* Exceptions pour le caractère '_' : Personnelement j'utilise toujours le caractère underscore dans 2 cas.
o a_xxx : pour les paramètres (quelques exceptions)
o l_xxx : pour les variables locales à une méthode (exceptions : retour, len, variable à 1 lettre)

---

Mon but est de récupérer une structure comme celle des entity, mais en DTO allégés par rapport au entity correspondante.

Si je fais

Code:

---

String query = "SELECT p FROM Personne p left join fetch p.publicationList"

---

Je vais me retrouver avec 2 entity "Personne" composées chacune de 2 String un Long et une liste d'entity "Publication".

Tandis que si je fais

Code:

---

Query lo_query = em.createQuery("SELECT NEW dto.PersonneDTO(p.id,p.nom,p.prenom,p.age,pl) from Personne p left join p.publicationList pl");

---

Je me retrouve avec 6 DTO "PersonneDTO" composés chacun de 2 String , un Long et 1 publication. Je dois donc faire un post traitement pour supprimer les doublons "Personne" et construire les listes de publication pour me retrouver avec un modèle proche des mon modèle entity. Je voulais donc savoir si c'était possible en EJBQL ou d'une façon plus "propre" d'arriver au même résultat (ou si je fais fausse route :roll: ) .

Je sais pas si c'est tout à fait similaire mais je procède de la sorte pour un entity Cd lié à Artist par @ManyToMany :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

@Entity @Table(name="cd") public class CdEntity { private Integer id; private String name; private List<ArtistEntity> artists;   public CdEntity() { }   public CdDTO toDTO(){ ArrayList<Integer> artists_fk = new ArrayList<Integer>(); for(ArtistEntity artist : this.artists) artists_fk.add(artist.getId()); return new CdDTO(this.id, this.name, artists_fk); } }

---

J'ai personnellement choisi d'enregistrer dans le DTO uniquement les identifiants des Artist pour éviter un appel circulaire. Je n'ai donc aucun soucis à faire ensuite :

Code:

---

1 2 3 4 5 6

List<CdEntity> cds = em.createQuery("FROM CdEntity c ORDER BY c.id").getResultList(); ArrayList<CdDTO> resultList = new ArrayList<CdDTO>(); for(CdEntity obj : cds){ resultList.add(obj.toDTO()); } return resultList;

---

Je pourrais je pense rajouter une jointure sans aucun problème à ma requête. La seule différence, c'est que la liste qui est associée à mon CD ne contient pas la liste des artistes mais la liste des identifiants des artistes. J'ai pas trouvé de solution directe à ton problème sans appels circulaire ou un toDTO() sur la liste liée produit une autre itération de toDTO() sur une liste du premier objet et ainsi de suite jusqu'au stack overflow.

Je sais pas si c'est exactement la réponse que tu cherchais, ma façon t'intéresse peut être. C'est pas exactement ce qui est le plus pratique à utiliser, un peu plus à faire en dehors de la requête.

Merci pour ta réponse mais c'est n'est pas tout à fait ce que je recherche.

En effet, je veux utiliser des DTO pour 2 raisons:
1. Ne pas chercher en DB des données dont je n'ai pas besoin.
2. Ne pas faire transférer ces données inutilement.

Dans ton cas c'est OK pour le point 2 mais pas pour le premier. En effet tu va chercher toutes les infos d'un artiste en DB et ce n'est qu'après que tu fais le tris (Seulement les id si j'ai bien compris).

Puis j'avoue que j'aime bien l'idée d'appeler le constructeur du DTO directement dans la requête ejbql :)

Code:

---

1 2 3

En effet, je veux utiliser des DTO pour 2 raisons: 1. Ne pas chercher en DB des données dont je n'ai pas besoin. 2. Ne pas faire transférer ces données inutilement

---

Les 2 raisons se valent complètement, Le concept de DTO en lui même est plutot pas mal, mais je trouve que c'est rajouter quand même du code qui n'est pas forcément indispensable, en EJBQL ou JPQL tu peux très bien effectuer une requête qui ne te renvoie que les colonnes souhaitées, je t'avais montré un exemple plus haut, et tu récupères le resultat en collection<Object[]> l'avantage de cette méthode c'est la généricité, une seule méthode de ton entity manager traitera tes requetes soumises, alors que dans le cas des DTO, à chaque nouvelle requête composée, il te faut un nouveau DTO, je trouve ca perso un peu lourd à maintenir.Faire également un show_sql=true pour voir la requêtes générées par hibernate pour composer ton DTO, ca doit être une réquête énorme qu'il génére :mouarf:.
Après ce n'est qu'un avis perso.

Puisque le sujet dérive un peu sur l'utilisation des DTO, je vais mettre ici mon avis sur la question. Ca fait des mois que je réfléchis sur la question "dois-je transformer mes entity en DTO ou pas?". Il est clair que le DTO est un overhead relativement lourd à gérer (conversion dans un sens puis dans l'autre). Par contre, ça évite quand même quelques mécaniques inhérentes à l'architecture Java EE, notamment le fait qu'un entity est associé à un manager de persistence, et que celui-ci n'est plus disponible quand on sort du conteneur EJB (typiquement en donnant au conteneur Web, par exemple un servlet). Soit on passe par un DTO, qui "cache" cette mécanique, soit on fait bien gaffe à gérer les entity qui sont en statut "detached". La mécanique de re-synchronisation n'est pas lourde en soit, mais il faut pas l'oublier à un endroit (sous peine de comportement arbitraire ou d'exception gênante). L'avantage du DTO, c'est que quoi qu'il arrive, on ne peut pas oublier la de faire une conversion.

Code:

---

ça évite quand même quelques mécaniques inhérentes à l'architecture Java EE, notamment le fait qu'un entity est associé à un manager de persistence, et que celui-ci n'est plus disponible quand on sort du conteneur EJB

---

ötes moi d'un doute stp, tu n'es pas entrain de dire que pour chaque entité presente dans ton appli tu as un entitymanager? 8O

Heu... nan :mouarf::mouarf:

J'ai un manager de persistence pour tous les entities (ou parfois des groupes si je veux lier logiquement certaines parties de l'application séparément d'une autre partie ou sur des supports différents).

Otes moi d'un doute également... ça change quelque chose à ma réponse d'avoir un ou plusieurs manager ?

On est vraiment entrain de s'écarter du sujet de départ...
Un manager de persistence n'est pas forcément égal à un manager d'entités.Donc tu ne réponds pas ma question, en clair si t'as une entité de manager par entité, c'est pas bon, une entité ne doit normalement pas avoir connaissance de l'entitymanager. j'en ai toujours un seul pour toute l'application, qui d'ailleurs est souvent injecté par spring. J'espère que tu ne crées pas un entitymanager par entité, car j'ai vu cette facon de faire dans certains posts, dans ce cas quand tu veux synchroniser les entités avec la base que fais tu? une boucle de flush sur tous les entitymanages présents dans l'appli? C'est vraiment une horreur de programmation :mouarf:

Effectivement, on déborde un peu, je vais clôturer ici avec cette remarque : Mes Entities n'ont pas connaissance de mon EntityManager qui est à un niveau au dessus, dans le service d'intégration. Je comprends toutefois ceux qui pourraient avoir envie de mettre ça dans les Entities.

Citation:

---

Envoyé par Lethal

Dans ton cas c'est OK pour le point 2 mais pas pour le premier. En effet tu va chercher toutes les infos d'un artiste en DB et ce n'est qu'après que tu fais le tris (Seulement les id si j'ai bien compris).

---

Tout à fait, lors de la conversion en DTO seul les identifiants des objets CD's liés sont mis dans le DTO de l'artiste. Mais la totalité des données est extraite de la base de données. Je trouve d'ailleurs un peu spécial de vouloir extraire une partie seulement des données et de retourner un objet "incomplet". Ou tu as deux DTO différents, l'un complet et l'un simplifié ?

Citation:

---

Envoyé par Lordsephiroth

Tout à fait, lors de la conversion en DTO seul les identifiants des objets CD's liés sont mis dans le DTO de l'artiste. Mais la totalité des données est extraite de la base de données. Je trouve d'ailleurs un peu spécial de vouloir extraire une partie seulement des données et de retourner un objet "incomplet". Ou tu as deux DTO différents, l'un complet et l'un simplifié ?

---

C'est surtout dans le cas de listings ou je dois faire une requête sur 3 tables par exemple et ou je n'ai besoin que d'un id et d'un libellé pour chaque table. Je trouve ça pas vraiment optimisé d'aller chercher les 10 colonnes de chaque table alors que j'ai besoin de récupérer 3 id et 3 libellés.

Je trouve un peu à l'encontre de l'abstraction fournie par la plate-forme que de chercher à tronquer les objets ou sortir de la gestion offerte par le serveur pour faire quelque chose d'un peu plus manuel. Mais je comprends ce que tu cherches.

Dommage que la consistence des données dus au système de persistence ne permette pas de faire de requête directe dans la base en SQL brut. Pour un listing en read-only ce serait nettement plus optimisé de sortir ça directement, quitte à gérer le reste de manière standard par Entity.

Toujours le même trade-off... simplicité et abstraction versus efficacité et performance...

Code:

---

Dommage que la consistence des données dus au système de persistence ne permette pas de faire de requête directe dans la base en SQL brut.

---

C'est une affirmation ou une question? Car si c'était une affirmation elle serait fausse, tu peux très bien faire les natives query, le framework le permet, mais perso je déconseille.

Code:

---

C'est surtout dans le cas de listings ou je dois faire une requête sur 3 tables par exemple et ou je n'ai besoin que d'un id et d'un libellé pour chaque table. Je trouve ça pas vraiment optimisé d'aller chercher les 10 colonnes de chaque table alors que j'ai besoin de récupérer 3 id et 3 libellés

---

J'espère que tu as bien compris que sans DTO tu peux très bien faire une requete EJBQL ou JPQL qui ne t'extraie que les colonnes dont t'as besoin.Si tu changes d'avis sur le procédé (hors DTO) je pourrai t'aider sur la requete et la recupération du resultat, tu verras que c'est vraiment pas compliqué et hyper rapide à faire. Il suffit de savoir caster c'est tout.

Je me suis mal exprimé. On peut naturellement ouvrir une connection à une DataSource et faire du SQL natif. Par contre, on peut être surpris du résultat. La plate-forme EJB peut garder des choses en cache et ne pas les écrire immédiatement sur support physique, à moins de faire des flush manuels (si j'ai bonne mémoire). C'est pas qu'on ne peut pas, c'est plutôt que la cohérence des données ne peut pas être assuré à 100% (même si ça marchera 99% du temps).

Pour ton second commentaire, effectivement, je suis pas 100% au clair sur l'EJBQL. J'ai bien compris que tu crées des objets partiels et que ton problème vient uniquement de la jointure qui te fait une liste plate au lieu d'avoir une liste dans chaque objet de ta liste. Je n'ai personnellement pas besoin actuellement de prendre des objets partiellement, j'ai des trop faibles quantités de données. Merci de la proposition quand même ;)

Code:

---

Je me suis mal exprimé. On peut naturellement ouvrir une connection à une DataSource et faire du SQL natif.

---

Non pas jusque là, l'entitymanager te permet directement de soumettre des requetes natives, sans avoir besoin d'aller ouvrir ailleurs d'autres connections ailleurs, enfin bref.

Merci de la remarque, c'est une info que je n'avais pas. Je retiens pour la creuser plus profondément si j'en ai besoin. Je pensais que le choix était de choisir EJBQL ou du SQL natif à travers JDBC.

J'ai encore dérivé une seconde fois de ton sujet principal... en tentant d'y revenir... décidément... mes excuses :oops:

Comme je le pensais on commence à avoir la même conversation qu'avec mes collègues depuis 2 semaines. Je serais vraiment interressé de trouver un document, livre,... sur des best practices sur tout ce qu'on vient de parler. Car dans les documents que j'ai lu c'est toujours des petits exemples avec une ou deux jointure et 3 colonnes dans chaque tables. Mais quand on se retrouve avec un gros projets, bcp de tables et bcp de données on sait pas toujours quoi faire. Si vous voyez ça, faites signe ;)

je me posais une question vis à vis de ton problème d'entity allégé, n'est-il pas possible de faire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

@EJB public class entiteAllege{ @id private long id; @column private String name; [...] }   @EJB public class entite extends entiteAllege{ @column private String champ1 [...] }

---

Je prend mes désirs pour des réalités :D

par contre un truc qui pourrait peut être marcher:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

@EJB public class entiteAllege{ @id private long id; @column private String name; [...] }   @EJB public class entite { @id private entiteAllege id; @column private String champ1 [...] }

---

et sinon encore une autre solution qui cette fois a d'après moi plus de chance de marcher, mais bien moins joli :?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

@EJB public class entiteAllegeEjb{ @id private long id; @column private String name; [...] }   @EJB public class entiteEjb { @embededid private entiteAllegeIdid; @column private String champ1 [...]   @Embaddable class entiteAllegeId{ @id private long id; @column private String name; } }

---