Discussion :

[questionneuse]

Voici l'énoncé d'une question d'exam:

On doit concevoir un site J2EE de commerce en ligne .
Ce site offre un catalogue de produits et est capable de prendre les commandes des clients.
Comme tout magasin il gère un stock .
Les clients doivent pouvoir au cours d'une visite sélectionner plusieurs articles et effectuer un paiment.

Donner les beans et leurs types...

j'ai pensé a ceci:

on aura 3 tables dans la base:
*client avec 5 colonnes: nom, prenom, adresse, email, numclient
*stock avec 2 colonnes:numproduit, quantité
*commande avec 4 colonnes: numcommande,numclient,numcarte et numproduit.


on aura alors un EJB pour gérer les tables
pour client , un EJB pour Stock et un EJB pour commande.


pensez vous que l'ejb client est vraiment nécéssaire ou bien commande et stock suffisent.


ou bien je raconte n'importe quoi..

[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java

[dlemoing]

Réponse rapide : pas d'EJB (J2EE != EJB), on fait tout à base de javabeans.

on aura alors un EJB pour gérer les tables

C'est à dire ? Un EJB Session qui utilisera une connexion à une base de données ?

pour client , un EJB pour Stock et un EJB pour commande.

Des beans entity ? A notre époque ca se fait encore ? CMP ou BMP ? (CMP j'espere si tu pars dans cette voie)

pensez vous que l'ejb client est vraiment nécéssaire ou bien commande et stock suffisent.

Je pense qu'aucune EJB n'est nécessaire.

Questions :
- tu es obligé d'utiliser des EJB ?
- si oui, EJB 2.x ou 3.0 ?

[questionneuse]

ben le prof attend une réponse avec des EJB

il faudrait un ejb pour commande et pour stock, ce serait des cmp.
C'est une mauvaise idée tu penses

en fait je voulai en faire pour client pour pouvoir créer des client a partir d'une page jsp..

et sinon ca serait version 2.x

[dlemoing]

ben le prof attend une réponse avec des EJB

Ca ne veut pas dire que c'est un choix intelligent, il s'agit d'une contrainte comme une autre que tu pourras rencontrer dans la vraie vie.

il faudrait un ejb pour commande et pour stock, ce serait des cmp.
C'est une mauvaise idée tu penses

Faire des EJB entity c'est une mauvaise idée (dans les versions 1.x et 2.x), maintenant s'il s'agit d'une contrainte tu n'as pas le choix. Utilises des EJB CMP, tu auras moins de code à écrire et les performances sont meilleures. Par contre, utilis

en fait je voulai en faire pour client pour pouvoir créer des client a partir d'une page jsp..

Je comprends pas ce que tu veux dire...

[questionneuse]

Faire des EJB entity c'est une mauvaise idée (dans les versions 1.x et 2.x), maintenant s'il s'agit d'une contrainte tu n'as pas le choix. Utilises des EJB CMP, tu auras moins de code à écrire et les performances sont meilleures. Par contre, utilis

je voulais savoir en fait si dans le cas ou je décide de faire des EJB il faudrait en faire un pour commande et un pour stock ou juste un pour stock ..

en fait je voulai en faire pour client pour pouvoir créer des client a partir d'une page jsp..

Je comprends pas ce que tu veux dire...

En fait je pensais que lorsque le client s'enregistrerait dans une page jsp, on pourrait créer un client dans la table client par l'intermédiaire de L'ejb client.
On pourrait mettre un session bean qui servirait d'intermédiaire entre l'ejb et la jsp mais est ce nécéssaire..

[dlemoing]

je voulais savoir en fait si dans le cas ou je décide de faire des EJB il faudrait en faire un pour commande et un pour stock ou juste un pour stock ..

Si tu dois faire une appli qui utilise betement les EJB, fait un entity pour chaque.

En fait je pensais que lorsque le client s'enregistrerait dans une page jsp, on pourrait créer un client dans la table client par l'intermédiaire de L'ejb client.
On pourrait mettre un session bean qui servirait d'intermédiaire entre l'ejb et la jsp mais est ce nécéssaire..

Tu es libre de faire ce que je veux, mais personnellement :
- pas d'accès direct à un EJB entity, utilisation d'un EJB Session en tant que facade
- pas de code dans des JSP, utilisation des servlets pour appel aux EJB

[questionneuse]

Excuse moi d'insister mais d'aprés toi ca sera vraiment utile de faire cette ejb pour client ou pas parceque j'avoue qu'en discutant avec d'autre étudiant ils m'on dit de faire un classe client et point , pas besoin d'ejb , mais j'avoue que comprend pas trop bien comment ca marcherait avec une unique classe client qui contiendrait des getter et des setters

sinon autre question :

qu'est ce qu'une méta donnée?
et une méta base??
j'ai pas trop bien compris ce point dans mon cours.
il est juste dit "la méta base contient des info sur les tables contenues dans la base."

autre question:

comment peut on apeler une jsp a partir d'un servlet?
et vice versa ?
je sais que lorsque l'utilisateur a accés a la jsp la première fois elle est compilé et sauvegardé sous forme de servlet dans le moteur java.
Ensuite les fois suivante l'utilisateur a accés au servlet, c'est donc plus rapide.

Mais ca ne répond pas a la question

dernière question :

lors d'un traitement d'une requete dans une appli combinant 1 jsp 1 ejb et 1 jdbc, comment seraient géré les sources??
(ex. nbre de connexions ouvertes, nbre de processus légers et accés concurrents)

d'aprés moi , il faut une connexion jdbc:odbc:bd avec bd le nom de la base de données
processus léger je vois pas quoi mettre .
accés concurrents: je vois pas ce qu'il attend ben y en a plusieurs et alors quoi ??

vraiment cet exam est pas évident

[Hikage]

pour client , un EJB pour Stock et un EJB pour commande.

Des beans entity ? A notre époque ca se fait encore ? CMP ou BMP ? (CMP j'espere si tu pars dans cette voie)

pensez vous que l'ejb client est vraiment nécéssaire ou bien commande et stock suffisent.

Je pense qu'aucune EJB n'est nécessaire.

Questions :
- tu es obligé d'utiliser des EJB ?
- si oui, EJB 2.x ou 3.0 ?

Par simple curiosite, j'ai cru comprendre que les EJB n'etait pas trop bien vu.
J'apprends cela au cours, et bon j'aimerai comprendre quels sont les defauts qui font que ce n'est pas utile / pratique ?

[questionneuse]

je pense qu'ils sont pas pratiques parcequ'ils faut se taper des interfaces des classes et des descripteurs et tout ca c'est chiant.pour les 2.x

alors qu'avec hibernate on se tape un pojo par table et c'est ok ..

avec 3.0 il reprennent le modèle de persistence d'hibernate avec les pojo , je crois qu'il n'y a plus besoin de descripteur ..

[agougeon]

Avec 3.0 plus de souci effectivement il utilise des meta donnees...
Tu mets

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
@EJB statefull

devant la declaration de ta classe et boom, voila ton POJO qui devient un EJB

[questionneuse]

Avec 3.0 plus de souci effectivement il utilise des meta donnees...
Tu mets

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
@EJB statefull

devant la declaration de ta classe et boom, voila ton POJO qui devient un EJB

mais justement tu vas pas tenter de m'aider a a répondre a ces question précédentes,
je sèche c'est quoi ces méta donnees , ce sont des données de la méta base , mais quel est la différence entre la méta base et la base ?

De l'aide svp

[agougeon]

ousp, excuz je suis juste intervenu pour parler des EJB 3.0 sinon je suis vraiment pas callé EJB et surtou pas 2.x alors sinon si tu veux mon point de vu, bah tu n'a qu'a te dire que EJB Entity = POJO donc tu fais un EJB par table. Mais je suis pas sur de moi :S

[questionneuse]

ousp, excuz je suis juste intervenu pour parler des EJB 3.0 sinon je suis vraiment pas callé EJB et surtou pas 2.x alors sinon si tu veux mon point de vu, bah tu n'a qu'a te dire que EJB Entity = POJO donc tu fais un EJB par table. Mais je suis pas sur de moi :S

oui justement c'est ma manière de penser mais je suis pas sur que ce soit la bonne c'est pour ca que j'ai besoin d'aide..

[a_defanti]

Pour les questions EJB Entity, Session, certains design pattern à implémenter pour améliorer les perfs, tu peux te référer à la doc de WSAD
http://www.redbooks.ibm.com/abstracts/SG246993.html?Open

Il y a un exemple de dév avec ses sources.

[dlemoing]

oui justement c'est ma manière de penser mais je suis pas sur que ce soit la bonne c'est pour ca que j'ai besoin d'aide..

Ca dépend de ce que tu souhaites faire (et de la personne qui note).
Si tu veux respecter l'énoncé, tu vas :
- faire 1 EJB entity pour chaque classe (client, stock, commande, produits, etc...)
- faire 1 ou plusieurs EJB Session (stateless) qui joueront le rôle de facade (c'est pas pour autant qu'ils doivent être remote)
- respecter les "patterns J2EE" (regarde ici)

Si tu veux faire un truc qui respecte un peu l'énoncé mais qui est bien meilleur :
- mapping objet-relationnel (tu sembles connaitre hibernate) pour modéliser un domain model plus ou moins riche
- une couche de persistance (DAO)
- une couche de service
- et (pour respecter l'énoncé), 1 ou plusieurs EJB session pour jouer le rôle de facade (délégation à la couche service) et gérer déclarativement les transactions

Dans le premier cas, tu respectes l'énoncé et tu fais ce qu'on te demande.
Dans le deuxieme cas, tu n'utilises pas intensivement les EJB (tu sors donc un peu du cadre) mais tu fais quelque chose de plus réaliste.