Discussion :

[Quartus]

Chers tous,

J'ai un petit souci en JSF, que faire quand les entity beans ne coresspondent pas à la vue. Je m'explique :

Imaginons, j'ai un entity User(userID, password) et je souhaite afficher dans la vue avec une datatable (userID, password, +qqch d'autre). Le truc c'est que je ne veux pas modifier mon entity car ce n'est pas chose à faire. Mais alors, ce nouvel objet, je dois le mettre dans une couche au dessus des EJB?

genre :

JSF Managed beans -> business object -> session bean -> entity bean

Merci pour vos réponses !

[DevServlet]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

J'ai un petit souci en JSF, que faire quand les entity beans ne coresspondent pas à la vue

Sur une contrainte architecturelle, un entity bean n'est pas censé correspondre completement à une vue,ce sont des objets de la 3e couche, si ca peut t'aider tu peux declarer des attributs en transient, primitive ordonnant à JPA de ne pas les persister. ca repond à ta question?

[Quartus]

Merci pour ta réponse. Je connaissait déjà la possibilité d'annoter @transient les attributs des entity beans pour skipper la persistance.

Cependant, je ne crois pas qu'il soit judicieux de procéder de la sorte. Serait-il plus judicieux de créer une couche au dessus des stateless beans comprenant les objets-vue?

Tous les avis sont les bienvenus !

[OButterlin]

Tu peux utiliser les DTO (Data Transfert Object), je trouve que c'est ce qu'il y a de mieux pour ce genre de problématique (et d'autres mais c'est un autre débat).
Du coup, ton EJB stateless/statefull renvoie une liste d'objets DTO, ceux-ci sont totalement indépendants de la persistance (charge à la méthode appelée de récupérer toutes les informations voulues).

Je suis d'accord avec toi pour ce qui est de rajouter des propriétés @Transient, ça n'a pas trop de sens dans la mesure où le chargement serait complexifié, on les utilise plutôt pour des données calculées par rapport à des attributs de l'entity (c'est mon avis en tout cas )

[Quartus]

Un tout grand merci pour ta réponse. Donc si j'ai bien compris, on a :

- une couche entity (objets persistés)
- une couche dto
- une couche dao (query sur les entity retournant des dto)
- une couche jsf managed beans (injection des ejb qui retournent les dto)

Donc en gros, un dto est quasimment un objet sans méthodes, je me trompe ?
(sans les get/set évidemment).

[Quartus]

Une remarque, est-ce que les DTO's doivent normalement étendre (extends) les entity beans?

[OButterlin]

Le DTO est juste une enveloppe des propriétés utilisées, donc, il n'a pas de méthodes autres que getter/setter.
Enfin, si tu en as besoin, rien n'empêche de le faire, par exemple pour ajouter à une liste etc...

Et non, les DTO "n'extends" pas les entity.

Les DTO sont très souvent décriés, on leur reproche d'être une copie des entity (ce qui est souvent le cas), mais ils permettent bien d'autres choses comme :

- l'indépendance entre la couche de présentation et le modèle de données (on peut faire évoluer le modèle de données sans avoir à retoucher une ancienne application)

- l'agglomération des données

- plus de problème de lazy loading en dehors du conteneur d'EJB
(toutes les données nécessaires et uniquement celles-ci sont lues et renvoyées)

[Quartus]

OK, je crois que je compris à présent.

Est-ce que ceci correspondrait à ce design pattern?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
@Entity
public class User{
private String id;
private String password;
}
 
public class UserDTO{
private User user;
private String qqch;
}
@Stateless
public class UserEJB{
public List<UserDTO> getUsers(){
...
}

[OButterlin]

Oui

[Quartus]

Un tout grand merci ! Tu m'enleves une bonne épine du pied.

Pour la postérité, je mets ce lien passionant (auquel tu as participé d'ailleurs)

http://www.developpez.net/forums/d44...esign-pattern/

[Quartus]

Juste pour info, pourrait-tu partager tes conventions de nommage pour les classes/packages des couches:

-entity
-dao
-dto
-managed beans

Merci !

[OButterlin]

Je n'ai pas trop "planché" sur la normalisation des noms, c'est un peu à chaque fois autre chose...
Pour les noms de classes, ce serait dans le genre :

Entity : généralement, le nom de la table

Utilisateur
Role
Service
...

DAO : généralement, le nom est lié à l'entité principale gérée quand il s'agit d'un CRUD

UtilisateurDAO
RoleDAO
ServiceDAO
...

DAO : non CRUD

GestionUtilisateursDAO


DTO :

UtilisateurCompletDTO
...

Il faut en plus mettre en relation avec la notion de façade...
Schématiquement, on accède par "GestionUtilisateur" qui dispatche vers les autres DAO si besoin.

Globalement, au niveau package, on peut voir les choses comme ceci :

com.lasociete.ejb.entity
com.lasociete.ejb.dto
com.lasociete.ejb.dao
com.lasociete.ejb.dao.crud

Pour la partie jsf, on est plus libre mais ça pourrait ressembler à ceci (par thème géré)

com.lasociete.utilisateur
com.lasociete.role
com.lasociete.service


Bref, rien de bien abouti... si ça se trouve, demain je ferai autrement