Version imprimable
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?
Toujours !
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%?
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
Je suis d'accord avec ego. J2EE != EJB
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.Citation:
Envoyé par ego
Le meilleur livre sur le sujet est son livre avec Juergen Hoeller : J2EE wihtout EJB.Citation:
Envoyé par ego
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.
et EJB sans J2EE c'est possible ?
(EJB 3 avec juste J2SE)
EJB fait partie de la spec J2EE, la phrase n'as pas de sens !
il est spécifié ici : http://java.sun.com/j2ee/letter/persistence.html que
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.Citation:
We believe this is a unique opportunity for the Java community to create a common POJO persistence model for both J2SE and J2EE
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 !
pour moi on a simplement remplacé la définition des interfaces par des anotations dans le codeCitation:
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 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
je pense qu'on parle d'hibernate, mais la on a pas attendu ejb3 pour que ce soit réalisable, heureusement!Citation:
We believe this is a unique opportunity for the Java community to create a common POJO persistence model for both J2SE and J2EE
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.
ack !Citation:
Envoyé par mauvais_karma
ça va peut etre changer avec la norme EJB3, qui fait jeux egal avec hibernate et JDO.Citation:
Envoyé par ego
Merci à tous pour ces eclaircissement