Entity dans Servlet

Bonjour,

J'ai 3 projets JPA, EJB 3.0 et WEB est il possible d'utiliser les accesseurs des entities du projet JPA dans ma servlet afin de par exemple setter les attributs d'un entity avant de le transmettre à l'EJB qui le persistera ?

Un exemple : Dans ma Servlet :

Code:

---

1 2 3 4 5 6 7 8 9

@EJB UserService userrService;   User user; <-- Entity JPA   public void test(){ user.setNom("test"); utilisateurService.creerUser(user); <-- qui à pour but de persister l'objet user }

---

Est ce dans ce sens ? Ou je dois transmettre la request à l'EJB qui lui s'occupera de setter l'objet user puis le persister ?

Merci beaucoup pour votre aide !

Il n'y a pas de raisce n'eon que tu ne puisse pas manipuler une entité retournée par un EJB. Attention par contre à ne pas stocker l'ejb dans les champs de la servlet, ce n'est pas l'endroit pour stocker un état :)

Merci tchize_ pour ta réponse .

Mon user ne provient pas de mon EJB mais directement de mon JPA j'utilise directement l'entity dans la servlet que je set mais celui çi est null ==> il n'est donc pas possible de faire comme cela ?
Effectivement j'ai créé une methode getUser dans mon EJB qui me renvoie mon user = new User() et maintenant je peux setter celui ci depuis ma servlet.

Que penses tu de passer la request à l'EJB c'est une mauvaise pratique afin de setter les attributs dans l'EJB et non dans la servlet ?

J'ai entendu dire que c'était mieux de rajouter une couche DTO entre le JPA et les EJB afin de pouvoir manipuler uniquement les DTO et non les entities mais comme les entities sont aussi des POJO alors je pensais que ça n'avait plus d'utilité..

Il vaut mieux setter les attribut de mon entity dans ma servlet ou dans mon EJB ? sachant que ma servlet fait normalement plus office de controleur.. je connais pas les bonnes pratiques avec EJB et JPA..

Merci pour vos réponse et de m'éclairer un peu sur le sujet.

Citation:

---

Envoyé par Tom1x

Merci tchize_ pour ta réponse .

Mon user ne provient pas de mon EJB mais directement de mon JPA

---

Tu veux dire que t'injecte un entity manager dans ta servlet et que tu manipule l'objet qui en sort? Ça peut se faire, mais c'est mieux de mettre la logique business dans un objet dédié, Typiquement un EJB

Citation:

---

j'utilise directement l'entity dans la servlet que je set mais celui çi est null ==> il n'est donc pas possible de faire comme cela ?

---

faudrait que tu nous montres le code que tu utilises dans ta servlet pour récupérer ton user :)

Citation:

---

Que penses tu de passer la request à l'EJB c'est une mauvaise pratique afin de setter les attributs dans l'EJB et non dans la servlet ?

---

Tout ce qui est logique business devrait se trouver dans un objet dédié, la servlet n'est en général qu'une vue parmis d'autres possibles. Maintenant tu peux peupler ton objet User depuis ta servlet "create user", puis appeler l'EJB avec une méthode "createUser(User)", à charge de l'EJB de vérifier que le user est peuplé correctement puis de le stocker en base.

Citation:

---

J'ai entendu dire que c'était mieux de rajouter une couche DTO entre le JPA et les EJB afin de pouvoir manipuler uniquement les DTO et non les entities mais comme les entities sont aussi des POJO alors je pensais que ça n'avait plus d'utilité..

---

Personellement, comme les entités sont des pojos, je suis plutôt adepte de les utiliser comme DTO. Après, suivant les méthodes EJB, je vais retourner directement l'entité ou en faire une copie, mais je ne vois pas l'intérêt de créer une classe DTO qui aura au finalement exactement la même signature que l'entité. Exception faire des EJB remote où il est préférable de découpler, ça permet de faire évoluer l'entité sans affecter le DTO, ce qui permet de garder un retrocompatibilité avec les services attaquant tes EJB remote.
A trop jouer avec des DTO on fini avec des applications lasagnes où à chaque couche les données sont transférées d'un DTO à l'autre et le CPU passe son temps à copier des données.

Je faisais quelque chose comme ça dans ma servlet :

Code:

---

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

@EJB ServiceUtilisateurs serviceUtilisateurs;   Utilisateur utilisateur = new Utilisateur();   public ServletUsers() { super(); }   protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { utilisateur.setName = "nom"; <=== Erreur ici, utilisateur est null serviceUtilisateurs.createUser(utilisateur); }

---

Qu'est ce que tu veux dire par objet dédié ?

En faite est ce qu'il existe en Java EE un moyen standard de transmettre les info d'un formulaire JSP --> Servlet vers un EJB sans transmettre la request à l'EJB et sans transmettre une valeur une à une..
Ce qui m'éviterait de setter les valeurs dans la servlet à moins que ca soit un standard de le faire ainsi.. :question:

Merci pour tes conseils ils m'aident à comprendre !

Avec ce code, 'utilisateur' ne devrait pas être null, tu dois nous cacher une autre partie de ton code là. En plus je doute que ce code compile, on passe la valeur en argument au getter, on n'utilise pas l'opérateur d'assignation sur une méthode.

De toutes façons, comme je l'ai dit, on ne stocke pas d'état dans les champs de la servlet. Ce n'est pas bien. Ils peuvent être réinitialisés si la servlet est déchargée puis rechargée par le conteneur et ils sont partagés entre toutes les connexions.
Un code correct serait

Code:

---

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

@EJB ServiceUtilisateurs serviceUtilisateurs;     public ServletUsers() { super(); }   protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { Utilisateur utilisateur = new Utilisateur(); utilisateur.setName("nom"); serviceUtilisateurs.createUser(utilisateur); }

---

Citation:

---

En faite est ce qu'il existe en Java EE un moyen standard de transmettre les info d'un formulaire JSP --> Servlet vers un EJB sans transmettre la request à l'EJB et sans transmettre une valeur une à une..

---

Oui, les tapper dans un objet. En l'occurence, Utilisateur est un objet tout à fait aproprié pour le travail que tu veux faire ici.