J2EE : EJB vs JavaBean ? Quelles différences ?
Résolu/Fermé
Milly7534
Messages postés
26
Date d'inscription
jeudi 12 juin 2014
Statut
Membre
Dernière intervention
27 avril 2015
-
27 juin 2014 à 10:10
Milly7534 Messages postés 26 Date d'inscription jeudi 12 juin 2014 Statut Membre Dernière intervention 27 avril 2015 - 27 juin 2014 à 22:51
Milly7534 Messages postés 26 Date d'inscription jeudi 12 juin 2014 Statut Membre Dernière intervention 27 avril 2015 - 27 juin 2014 à 22:51
2 réponses
KX
Messages postés
16733
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
31 janvier 2024
3 015
27 juin 2014 à 19:24
27 juin 2014 à 19:24
Bonjour,
L'architecture Java EE c'est ça :
Alors, sauf miracle, il y a peu de chances que ton projet Java SE respecte cette architecture. Ça ne veut pas dire que tes classes doivent être réécrites pour que ça fonctionne, par contre pour respecter l'architecture n-tiers, à mon avis il faudra les remanier.
Ceci dit, pour répondre à la question :
Un Bean, c'est un objet qui ne fait généralement pas grand chose, il est avant tout là pour stocker des données, donc on aura des attributs privés, un constructeur sans argument et/ou un constructeur avec tous les arguments, des get/set/is public pour accéder aux attributs, sans oublier hashCode/equals/toString et c'est tout.
Les EJB ce sont eux qui font le travail, ce sont de grosses classes qui vont vraiment faire la partie opérationnelle de l'application. Il y a plusieurs types d'EJB selon s'ils sont font la relation entre l'application et les données (EJB Entité), les clients (EJB Session), ou d'autres applications (EJB message).
En gros divise tout en bloc, qui communiquent entre eux uniquement ce qu'ils veulent.
La couche d'accès aux données DAO sait comment est fait ta base de données, mais la seule chose qu'elle fait c'est prendre des Beans en paramètres, faire une requête, et donner des Beans en sortie.
La couche Business elle va faire le lien entre plusieurs DAO, et manipuler les Bean pour donner un tout cohérent.
La couche présentation, elle ne fait que présenter les données, elle ne les calcule pas.
Si dans ta page web tu veux savoir quel temps il fait, la couche présentation va demander au métier de lui renvoyer quel temps il fait. Pour cela la couche métier récupérer l'information, soit dans son cache si il a déjà l'information, soit auprès d'une DAO qui pourrait être une base de données, ou un autre site web, etc.
Dans tout les cas, on sépare bien les choses.
Remarque : les EJB ne sont pas systématiques, parfois surtout pour un war, les classes métiers sont toutes simples, ce qui ne t'empêchera pas d'avoir une architecture Java EE correcte pour autant.
Attention : si tu fais un select * directement dans ta page JSP, je mords ;-)
L'architecture Java EE c'est ça :
Alors, sauf miracle, il y a peu de chances que ton projet Java SE respecte cette architecture. Ça ne veut pas dire que tes classes doivent être réécrites pour que ça fonctionne, par contre pour respecter l'architecture n-tiers, à mon avis il faudra les remanier.
Ceci dit, pour répondre à la question :
Un Bean, c'est un objet qui ne fait généralement pas grand chose, il est avant tout là pour stocker des données, donc on aura des attributs privés, un constructeur sans argument et/ou un constructeur avec tous les arguments, des get/set/is public pour accéder aux attributs, sans oublier hashCode/equals/toString et c'est tout.
Les EJB ce sont eux qui font le travail, ce sont de grosses classes qui vont vraiment faire la partie opérationnelle de l'application. Il y a plusieurs types d'EJB selon s'ils sont font la relation entre l'application et les données (EJB Entité), les clients (EJB Session), ou d'autres applications (EJB message).
En gros divise tout en bloc, qui communiquent entre eux uniquement ce qu'ils veulent.
La couche d'accès aux données DAO sait comment est fait ta base de données, mais la seule chose qu'elle fait c'est prendre des Beans en paramètres, faire une requête, et donner des Beans en sortie.
La couche Business elle va faire le lien entre plusieurs DAO, et manipuler les Bean pour donner un tout cohérent.
La couche présentation, elle ne fait que présenter les données, elle ne les calcule pas.
Si dans ta page web tu veux savoir quel temps il fait, la couche présentation va demander au métier de lui renvoyer quel temps il fait. Pour cela la couche métier récupérer l'information, soit dans son cache si il a déjà l'information, soit auprès d'une DAO qui pourrait être une base de données, ou un autre site web, etc.
Dans tout les cas, on sépare bien les choses.
Remarque : les EJB ne sont pas systématiques, parfois surtout pour un war, les classes métiers sont toutes simples, ce qui ne t'empêchera pas d'avoir une architecture Java EE correcte pour autant.
Attention : si tu fais un select * directement dans ta page JSP, je mords ;-)
Hichamisto
Messages postés
52
Date d'inscription
jeudi 26 juin 2014
Statut
Membre
Dernière intervention
4 juillet 2017
3
27 juin 2014 à 11:26
27 juin 2014 à 11:26
pour la première question :
* Mes classes de départ ont-elles besoin d'être modifiées pour coller au modèle de J2EE ?
non, pas forcement, dans ton cas tu n'es pas obligé de changer quoi que soit dans le code.
mais tu dois ajouter une autre classe qui est une Sevlet pour pouvoir lier la page JSP avec tes classes déjà définit.
en faisant ce que je t'ai dit votre code devra marcher.
Bon courage
* Mes classes de départ ont-elles besoin d'être modifiées pour coller au modèle de J2EE ?
non, pas forcement, dans ton cas tu n'es pas obligé de changer quoi que soit dans le code.
mais tu dois ajouter une autre classe qui est une Sevlet pour pouvoir lier la page JSP avec tes classes déjà définit.
en faisant ce que je t'ai dit votre code devra marcher.
Bon courage
Milly7534
Messages postés
26
Date d'inscription
jeudi 12 juin 2014
Statut
Membre
Dernière intervention
27 avril 2015
27 juin 2014 à 11:36
27 juin 2014 à 11:36
Merci pour ta réponse ! Ca m'arrange alors ^^ Mais du coup, dans quels cas a-t-on besoin d'un bean ou d'un EJB ? Je n'ai pas compris leur utilité
Hichamisto
Messages postés
52
Date d'inscription
jeudi 26 juin 2014
Statut
Membre
Dernière intervention
4 juillet 2017
3
27 juin 2014 à 11:47
27 juin 2014 à 11:47
les EJB servent a standardise la façon dont sont construit les composant coté serveur pour des applications distribuées.
les composant, c'est a dire les beans sont des objets de grosses granulite représentant soit une fonctionnalité ( comme un panier Electronique sur le web ) soit des données (comme un bean client renfermant les information d'un client, c'est a dire l'objet Client en soit) .
Il existe une grosse différence entre ces deux types de composants, et c'est pourquoi les EJB se compose de deux types de composants : les Beans de session (session bean) et les bean d'entité (entity bean)
résumé :
bean session : pour accomplir un travail.
bean entity : pour représenter un objet persistant.
les composant, c'est a dire les beans sont des objets de grosses granulite représentant soit une fonctionnalité ( comme un panier Electronique sur le web ) soit des données (comme un bean client renfermant les information d'un client, c'est a dire l'objet Client en soit) .
Il existe une grosse différence entre ces deux types de composants, et c'est pourquoi les EJB se compose de deux types de composants : les Beans de session (session bean) et les bean d'entité (entity bean)
résumé :
bean session : pour accomplir un travail.
bean entity : pour représenter un objet persistant.
Milly7534
Messages postés
26
Date d'inscription
jeudi 12 juin 2014
Statut
Membre
Dernière intervention
27 avril 2015
27 juin 2014 à 15:38
27 juin 2014 à 15:38
D'accord, merci ! Mes classes n'ont pas l'air de rentrer dans ces compositions la
27 juin 2014 à 22:51