Version imprimable
Bonjour ,
je fais la conception d'une application ejb3,donc je veux comprendre le mecanisme des ejb coté client et coté serveur , et ou intervient les dao ,
Donc d'aprés ce que j'ai appris ,un client se connecte a une session client puis il choisit une methode (invoquer une methode qui s'applique sur un entity bean) puis cette methode est traité par le dao qui l'applique sur la table relationnelle correspondante.
Est ce que c'est juste ou non!!
Merci pour votre reponse
Bonjour,
DAO n'est plus forcément un bon concept pour les EJB3, c'est une histoire de troll. Conceptuellement, tu peux créer une classe service.. qui interroge tes objets JPA mappant la base de donnée. Bref le code "métier" peux être dans cette classe service.
Pour faire violent, mais propre
Client ( web ) <--> Managed Beans dans JSF <--> EJBremote ou local -> Classe Services -> POJO ( JPA )
rajouter la couche service te permets de créer des tests unitaires en dehors du conteneur D'EJB. service == code métier.
j'utilise Glassfish et un modèle que je trouve propre.
olivier
bonjour,Citation:
Envoyé par nathieb
merci pour votre réponse:ccool: , que signifie "<--> "et " ->" et ou intervient le cote base de donnée .
Merci encore
Bonjour,
le --> et <-> sont une erreur de ma part. Ils sont tous <-->, qui exprime un dialogue ou une relation.
La partie base de donnée est représenter par des POJOS java en utilisant JPA. Le fameux mapping relationnel ou ORM.
olivier
Merci beaucoup toute est claire :ccool:!!!Citation:
Envoyé par nathieb
Petites précisions en passant...
Il n'est pas nécessaire d'utiliser un EJB session stateful côté serveur, un stateless peut très bien faire l'affaire...
Lorsqu'on utilise une interface Remote, les arguments sont passés par valeur alors qu'avec une interface Local, ils sont passés par référence.
Il est fortement recommandé d'utiliser le concept de facade pour améliorer les performances de l'application et éviter des aller/retour entre client et serveur.
Dans ce concept, on centralise les méthodes utililes dans un objet et son interface et c'est cet objet qui invoquera les autres EJB (de préférence via Local), ce qui ressemble à ceci
entre (1) et (2), on a un passage par valeur avec marshalling/unmarshallingCitation:
(1)client ---> (2)ejb facade (remote) ---> (3)ejb1 local
......................................................... ejb2 local
......................................................... ejb3 local (etc...)
entre (2) et (3), on a un passage par référence (donc direct)
Dans le cas d'une application web, on pourrait utiliser uniquement des interfaces Local (tous les traitements étant fait sur le serveur)
Dans le cadre d'une application client lourd (swing par exemple), il sera nécessaire de passer par Remote et de configurer correctement JNDI pour récupérer "l'initialContext" via jndi.properties ou en interne via un objet Properties
:PMerci beaucoup ca va vraiment m'aider dans ma conception: diagramme de sequence, composant et classeCitation:
Envoyé par OButterlin