Question d'un newbie en la subtile matière que sont les EJB.
 
J'ai fait un modèle de données relationnel pour représenter un arbre quelconque. Maintenant, j'aimerais faire des EJB pour gérer cet arbre (création de noeuds, suppression de noeuds, parcours, etc.). J'hésite entre faire un EJB entité qui représente mon arbre en entier et qui possède toutes les mèthodes qui m'intéressent (parcours, création de noeuds, etc.) ou faire plusieurs EJB entités représentant des noeuds et des chemins et qui seraient gérés par un EJB session.
 
Quelle est votre opinion là-dessus ?
 
Il faut savoir par ailleurs que l'arbre en question est le même pour tout le monde, il n'y aura que 2 ou 3 utilisateurs autorisés à le maintenir (je dis ça par rapport à une éventuelle problématique de cache).

bin normallement tu dois faire ca en Objet avant tout. Donc si tu as un arbre composé de noeud, tu peux faire une EJB noeud et utiliser l'OO pour construire ton arbre (par spécialisation et composition).
 
Pour ton session bean, ca n'a rien à voir. Tout dépend des fonctionnaités que tu fournis à tes users. Tu peux faire un session façade mais ca dépend si tu as une notion de session ou non.

C'est quoi "l'OO" ? Mon idée, c'était effectivement construire des objets simples du style "noeud", "chemin", etc. et les fédérer (i.e. gérer leur instanciation) dans un EJB entité appelé "Arbre". Est-ce valable ?
 
Sinon, ma question c'était aussi pour savoir si qq'1 voyait l'intérêt d'un EJB session, car a priori, je ne vois pas l'intérêt d'en avoir un : je ne pense pas qu'il y ait de session, sauf peut-être pour les utilisateurs qui vont gérer l'arbre (pour les autres utilisateurs, il n'y aura que la "lecture" de l'arbre dans son état actuel).

chuis d'accord avec DarkLord, quel intéret d'utiliser des Entity Beans si tu as concu un modèle de données relationnel et non objet?  
l'utilité des Entity Beans, c'est justement de te libérer de la conception relationnelle (surtout avec les CMP).
 
sinon si tu veux vraiment utiliser des Entity Beans, il est fortement conseillé d'appliquer le design pattern Session Facade, pour éliminer les gros problèmes de performances liés à l'utilisation des Entity Beans (surtout 1.1), sauf si ton modèle objet est trés simple (genre moins de 5 classes et pas trop de relations)
 

OO = Orienté Objet
 
l'intérêt d'avoir un EJB Session ?  ben pouvoir gérer cet objet en session quoi ... soit tu en as besoin, soit c'est pas le cas ...

_guigui_ a écrit a écrit :   sinon si tu veux vraiment utiliser des Entity Beans, il est fortement conseillé d'appliquer le design pattern Session Facade, pour éliminer les gros problèmes de performances liés à l'utilisation des Entity Beans (surtout 1.1), sauf si ton modèle objet est trés simple (genre moins de 5 classes et pas trop de relations)

 
quel rapport avec les perfs ?

 
les EJB en CMP c'est mega lourd !

en quoi une facade va régler le problème ?

Désolé de vous interrompre, mais là, ça va un peu trop loin par rapport à ce que je connais des EJB.
 
Pour moi, un des buts des EJB entité est de "mapper" un modèle relationnel sur une conception objet. Dans mon modèle, j'ai une table centrale qui s'appelle "noeuds" et qui boucle sur elle-même pour représenter la notion de parent. A côté de ça, j'ai une autre table ("fils" ) qui me permet de représenter la notion de fils ; ça doit me servir à parcourir l'arbre dans le sens descendant.
 
Vous êtes d'accord avec ça, ou pas ?

alors les pbs de perf (je parle pas du développement bien chiant)des Entity Beans:
on a un modèle distribué, c'est à dire que pour appeler une méthode de ton Entity Bean, ca passe par RMI, donc tu as des appels de JVM à JVM, voir à travers le réseau
bon tu me diras c'est pareil avec les Session Beans...
oui MAIS dans tes Entity Beans on a ce qu'on appelle une "granularité fine", tu as des getters et des setters sur les attributs de l'objet métier, alors que tu n'as que des méthodes dans le session bean...
autrement dit, avec l'entity bean, à chaque fois que tu veux récupérer un attribut, BLAM appels RMI de partout d'où baisse énorme des perfs!  
alors qu'avec un session bean devant, tu fais getEntityBean, et hop tu récupère tout d'un coup  
 
bon c'est ce que j'ai compris du facade pattern, en gros c'est ca
 
EDIT: oups désolé pour le squattage de topic

ben c'est plutot le contraire, tu fais une conception objet, parce que c'est quand même ca qu'on est censé faire quand on fait du java hein  
dans ton cas, tu fais un objet "noeud", un objet "fils", et aprés ben tu fais tes méthodes comme tu veux pour parcourir ton arbre.
si tu fais des Entity Beans CMP, tu n'auras même pas besoin de t'occuper tu mapping objet/relationnel, c'est automatique.

guigui -> ok.
 
mais on est d'accord, ce n'est utile que si les objets facade ne sont pas qu'un simple "raccourcis" vers les methodes des entity, sinon ca sert a rien : il faut qu'il 'factorise' plusieurs traitement consécutifs sur l'entity (ces traitements seront réalisés en local => plus rapidement)

_guigui_ a écrit a écrit : bon c'est ce que j'ai compris du facade pattern, en gros c'est ca

 
c'est un peu réducteur mais pour les perfs l'idée est là

DarkLord a écrit a écrit :     c'est un peu réducteur mais pour les perfs l'idée est là

à quel niveau c'est réducteur? si tu veux développer ca m'intéresse
l'autre pb des Entity Beans, c'est évidemment le temps de développement, avec 3 classes par objet (4 avec la classe key), plus les descripteurs XML, plus le session bean si tu fais ca bien, c'est  HORRIBLEMENT lourd...

vi vi  

Conclusion, je fais quoi ????  

_guigui_ a écrit a écrit :   à quel niveau c'est réducteur? si tu veux développer ca m'intéresse l'autre pb des Entity Beans, c'est évidemment le temps de développement, avec 3 classes par objet (4 avec la classe key), plus les descripteurs XML, plus le session bean si tu fais ca bien, c'est  HORRIBLEMENT lourd...

 
je peux mais pas tout de suite

DarkLord a écrit a écrit :     je peux mais pas tout de suite

je te le rappelerai tu vas pas te défiler comme ca

C'est quoi, alors, vos idées sur la façon d'utiliser les EJB ???

mon idée à moi c'est de les utiliser uniquement si c'est VRAIMENT nécessaire ...
je trouve ca super lourd et contraignant.  
 
Maintenant, y a beaucoup de projet pour lequel les EJB sont très utiles, mais le choix EJB-pas EJB ne doit pas être fait à la légère : y a une bonne marge de JH entre les 2 !

 
A mon avis, dans un contexte full J2EE et pour ce que je veux faire, c'est tout vu : c'est EJB, et rien d'autre...

 
pas d'accord. C'est vraiment trop lent. Le seul truc de vraiment valable au niveau EJB c'est les asynchronous message bean dans EJB 2.0
 
Pour le reste ...

Vous feriez quoi, alors ? Un truc tout con qui fait un lookup sur le data source de la base de données, et c'est tout ?

nan  
pour ce que tu veux faire, l'idéal, c'est JDO (Java Data Objects).
Je vais pas tarder à mettre mon rapport de stage en Francais en ligne (5 mois de stage JDO ), mais en attendant si l'anglais te rebute pas, www.jdocentral.com www.libelis.com
 
 
EDIT: t'as le droit de te faire tes objets et le mapping objet relationnel à la mimine avec JDBC, t'es pas obligé d'utiliser les EJB ou JDO (sauf si tu veux la gestion des transactions, les notions de sécurité qu'apportent les EJB)

_guigui_ a écrit a écrit :   nan   pour ce que tu veux faire, l'idéal, c'est JDO (Java Data Objects). Je vais pas tarder à mettre mon rapport de stage en Francais en ligne (5 mois de stage JDO )

je peux te dire que je suis vachement impatient de le lire !!!!!!!  

j'ai juste quelques paragraphes à virer, genre la présentation de l'entreprise, les remerciements, les logos de la boite etc etc...
faut que je fasse ca un de ces soirs j'ai la flemme...

_guigui_ a écrit a écrit : j'ai juste quelques paragraphes à virer, genre la présentation de l'entreprise, les remerciements, les logos de la boite etc etc... faut que je fasse ca un de ces soirs j'ai la flemme...

dit toi que tu as déjà un lecteur d'assuré !!!  

benou a écrit a écrit :   dit toi que tu as déjà un lecteur d'assuré !!!

 
  2

_guigui_ a écrit a écrit : j'ai juste quelques paragraphes à virer, genre la présentation de l'entreprise, les remerciements, les logos de la boite etc etc... faut que je fasse ca un de ces soirs j'ai la flemme...

 
ca m'intéresse aussi !

Dire que depuis des années, ce genre de choses se fait tout seul par les SGBDOO...

BifaceMcLeOD a écrit a écrit :   Dire que depuis des années, ce genre de choses se fait tout seul par les SGBDOO...

j'attend tjs d'en voir un qui me convainc...
de plus tu peux difficelement intégrer ça dans un système existant...

Ben si, justement, c'est une des facilités de tout système objet... Donc des SGBDO en particulier (attention, je parle de vrais SGBD, avec gestion des transactions, intégrité référentielle, etc...)
 
Te convaincre de quoi ? Que c'est viable ?

commode à utiliser

Je t'en donne une idée en Java :

ha .... les sgbdoo ... ca me rapelle mes études !
 
c'est de quel sgbdoo dont tu te sers ?

J'ai arrêté d'utiliser. J'utilisais O2. Mais le code ci-dessus est valable pour la plupart des SGBDO du marché.

je me trompe pas ? elle a fermé la boite qui éditait O2 ?

ouais
euh
ok
(select blablablabla->ben j'esperais plus avoir ça moi )