Bonjour,
J'ai fait un schéma sur l'utilisation des EJB et j'aimerais savoir si quelqu'un veut bien me dire ce qu'il en pense et surtout s'il ne comporte pas d'erreur évidente ?
Merci d'avance pour votre aide.
Version imprimable
Bonjour,
J'ai fait un schéma sur l'utilisation des EJB et j'aimerais savoir si quelqu'un veut bien me dire ce qu'il en pense et surtout s'il ne comporte pas d'erreur évidente ?
Merci d'avance pour votre aide.
Bonjour, ton schéma me va bien mis à part quelques petite bémols à modifier, que je ne peux hélas pas bien te décrire, serait il possible de numéroter toutes les flèches et nous retransmettre le fichier?ainsi on pourra te faire un retour bien précis
voilà j'ai rajouté des numéros
1 application standalone javaSE utilisant un Session Bean en mode Remote
2 et 3 Session Bean utilise un EntityBean EJB côté serveur (JBoss par exemple) avec gestion de la persistance des données via les méthodes persist,merge,etc... ou JQL ou sql natif
(avec utilisation DAO pour les méthodes)
4 - 2 - 3 idem à partir d'une application Web (l'application tournant sur serveur JBoss ou Tomcat - faire attention aux ports)
6 utiliser JPATools pour générer automatiquement les EJB à partir de la database (ou le faire manuellement avec les annotations OneToOne, OneToMany, ManyToMany)
5 si application Web (war) et module EE sur le même serveur ??
utilisation directe des EJB sans passer par les Session Bean
Evidemment, le schéma est simple mais c'est pour montrer à mes étudiants l'opportunité d'utiliser des EJB
Le but: répertorier les possibilités
je suis occupé à lire le livre de Fernandes 'Edition ENI' sur les EJB3
il décompose une application de vente ...
avec un exemple bien concrêt
si tu as d'autres références ...
A+
j'avais oublié le fichier (sorry) en attachment
A+
Bonjour, voila qui est mieux précisé pour t'aider.
1-La flèche 5 n'a pas lieu d'être, Le module controleur doit uniquement faire des injections de dépendances pour accéder à la logique métier(aux EJB si tu veux) et c'est aux EJB Session (stateless/statefull) d'aller chercher les entityBean (ce que t'as illustré par le flèche 4), pour moi la couche contrôler ne doit pas directement aller taper dans les entityBeans.Il faut voir les EJB Session comme des services.
2-La flèche 6 pour plus de précisions génère les entutyBeans.Les bean JPA,c'est ce que tu as voulu laisser entendre je suppose?
Pour le reste ça m'a l'air plutôt bien architecturé.
Si tu supprimes la flèche 5, ca veut dire :
- Des signatures à rallonge dans tes EJB (un update par exemple, tu vas fournir tous les champs présents dans l'entity ?)
- Qu'est ce que tu récupères lorsque tu charges une entité depuis les EJB ?
Du coup, supprimer la flèche 5 signifie adopter les DTO, la conserver signifie utiliser les entity beans à la place [Sujet controversé...]
Normalement dans une application il faut laisser tout ce qui est modification d'entités à la couche métier, les services ne devraient transmettre à la couche controleur que des Vues (ou DTO) si tu veux,objets à l'image des entités JPA, n'oublions qu'il peut y'avoir des contrôles metier à effectuer dans le services avant toute validation de modification. .Il faut avoir à l'esprit aussi qu'une entité JPA attachée et modifiée ce quelque soit la couche dans laquelle ça s'est fait sera prise en compte au moment du flush en base, c'est la raison pour laquelle il faut essayer dans la mesure du possible de déléguer ça à la logique métier.C'est ce qui explique d'ailleurs l'existence des framework comme Dozer. Donc en conclusion ne pas mettre la flèche 5 :mouarf: pour respecter ce principe de découplageCitation:
Envoyé par mikael.gibert
merci pour votre avis
A+