[Débat] Utiliser un framework de mapping O/R VS EJB

**trax020** · 27/10/2005, 17h01

Salut à tous,
Je pense ke tout le monde est d'accord ke les EJB sont lourds à mettre en oeuvre. Seulement quand on regarde l architecture J2EE on trouve dans la partie métier les Entreprise JavaBeans, et non des API comme JDO..
De façon générale, dans quel contexte justifie t on l usage de Hibernate ou OJB ou autres dans l elaboration de la couche métier plutot que d'utiliser les EJB?

**ego** · 27/10/2005, 17h17

Toujours !

**trax020** · 27/10/2005, 17h22

Autrement dit:si je fais parti d une entreprise, que je vais chez un client, que je lui présente l'architecture J2EE, qu'il constate que la partie métier est constituées d EJB, comment lui justifierai je l usage d'un framework de mapping O/R et ke finalement l application n a pas besoin d etre conforme a l architecture J2EE a 100%?

**ego** · 27/10/2005, 17h34

Ben déjà ta phrase est fausse ! J2EE (JEE maintenant) <> EJB
Ce qui se fait classiquement ceux sont des objets Java normaux, surtout pour les objets persistants et des EJB Session pour la gestion de la distribution, la sécurité et le transactionnel déclaratif.
Tes EJBs Session offrent ainsi une "interface J2EE" à tes objets Java classiques.
Il faut bien savoir pourquoi on utilise une technologie et ne pas l'utiliser comme ça parce que ça fait sympa dans les salons Java le samedi soir :-)
Il faut bien comprendre à quoi servent tous les composants / frameworks Java et ensuite, en fonction du contexte on en justifie l'usage.
Regardes ce que Rod Jonhson (créateur de SPRING) dit à propos des archi Java et tu comprendras

**dlemoing** · 27/10/2005, 22h14

Je suis d'accord avec ego. J2EE != EJB

Envoyé par ego

Ce qui se fait classiquement ceux sont des objets Java normaux, surtout pour les objets persistants et des EJB Session pour la gestion de la distribution, la sécurité et le transactionnel déclaratif.

On peut ajouter que toutes les applis ne nécessitent pas la distribution. Un framework comme Spring gère aussi les transactions de manière déclarative. Bref, cette approche "classique" était valable il y a 2-3 ans et l'est un peu moins maintenant.

Envoyé par ego

Il faut bien comprendre à quoi servent tous les composants / frameworks Java et ensuite, en fonction du contexte on en justifie l'usage.
Regardes ce que Rod Jonhson (créateur de SPRING) dit à propos des archi Java et tu comprendras

Le meilleur livre sur le sujet est son livre avec Juergen Hoeller : J2EE wihtout EJB.

Le premier livre de Rod Johnson (J2EE Design and Developement, 2002) utilisait l'architecture dont parle ego principalement pour la gestion déclarative des transactions. Son dernier livre (Professional Java Development whith the Spring Framework, 2005) montre comment aujourd'hui on peut faire exactement la même chose sans les EJB et avec Hibernate.

**NoP** · 28/10/2005, 00h21

et EJB sans J2EE c'est possible ?

(EJB 3 avec juste J2SE)

**Alwin** · 28/10/2005, 00h22

EJB fait partie de la spec J2EE, la phrase n'as pas de sens !

**NoP** · 28/10/2005, 00h31

il est spécifié ici : http://java.sun.com/j2ee/letter/persistence.html que

We believe this is a unique opportunity for the Java community to create a common POJO persistence model for both J2SE and J2EE

Mon anglais est pas terrible mais moi je comprend qu'on pourra utiliser la meme "syntaxe" pour faire persister nos objets aussi bien sur un serveur d'application que sur une application java standard.

C'est tout a fait possible car -si j'ai bien compris- les ejb devienne de simple objet java dans la norme 3(POJO). ils sont juste "enrichis" avec des annotation (@trucs) introduit dans Java 5 pour nous simplifier la tache.

Je me repete mais je débute donc j'attend qu'on m'éclaire un peu plus sur le sujet !

**mauvais_karma** · 28/10/2005, 09h39

C'est tout a fait possible car -si j'ai bien compris- les ejb devienne de simple objet java dans la norme 3(POJO). ils sont juste "enrichis" avec des annotation (@trucs) introduit dans Java 5 pour nous simplifier la tache.

pour moi on a simplement remplacé la définition des interfaces par des anotations dans le code
je pense pas que la tuyauterie derrière ait changé, sauf peut être pour les entity, en tout cas ca reste encore trop intrusif pour le code métier

We believe this is a unique opportunity for the Java community to create a common POJO persistence model for both J2SE and J2EE

je pense qu'on parle d'hibernate, mais la on a pas attendu ejb3 pour que ce soit réalisable, heureusement!

concernant ejb d'une facon générale, c un modele de composant qui apporte en plus des transaction, sécu, ... la distribution: ok personne en a besoin, sauf que pour une appli qui grossirait et pour laquelle on aurait besoin de plusieurs serveurs avec du load balancing et des services éparpillés, dans ce cas, ejb devient réelement interessant a mon avis

il faut juste etre réaliste quant au potentiel de son appli
et pui qui dit ejb dit serveur d'application, et la on s'improvise pas des compétences d'intégrateur ee.