J2EE : EJB vs JavaBean ? Quelles différences ?
Résolu
Milly7534
Messages postés
26
Date d'inscription
Statut
Membre
Dernière intervention
-
Milly7534 Messages postés 26 Date d'inscription Statut Membre Dernière intervention -
Milly7534 Messages postés 26 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
J'ai développé une application Java constituée de trois classes et d'un main pour l'exécution.
Je cherche à mettre en place une interface web qui remplacerait ce main.
Exemple : j'appuie sur un bouton HTML et une fonction d'une de mes classes est appelée et son résultat affiché dans une liste déroulante.
J'utilise donc J2EE mais après avoir lu plusieurs tutos, je mélange tout...Mes classes de départ ont-elles besoin d'être modifiées pour coller au modèle de J2EE ?
J'ai compris, de ce que j'ai pu lire, qu'une classe devient soit un JavaBean soit un EJB.
Comment savoir à quel type appartiennent mes classes ?
Merci d'avance pour votre aide !
J'ai développé une application Java constituée de trois classes et d'un main pour l'exécution.
Je cherche à mettre en place une interface web qui remplacerait ce main.
Exemple : j'appuie sur un bouton HTML et une fonction d'une de mes classes est appelée et son résultat affiché dans une liste déroulante.
J'utilise donc J2EE mais après avoir lu plusieurs tutos, je mélange tout...Mes classes de départ ont-elles besoin d'être modifiées pour coller au modèle de J2EE ?
J'ai compris, de ce que j'ai pu lire, qu'une classe devient soit un JavaBean soit un EJB.
Comment savoir à quel type appartiennent mes classes ?
Merci d'avance pour votre aide !
A voir également:
- Ejb
- Eclipse j2ee - Télécharger - Langages
- La =\= entre J2SE, J2EE et J2ME - Forum Programmation
- J2ee: variable session de Jsp vers Servlet ✓ - Forum Javascript
2 réponses
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 ;-)
Milly7534
Messages postés
26
Date d'inscription
Statut
Membre
Dernière intervention
Merci pour le schéma et les explications détaillées, c'est plus clair :)
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
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.
