Discussion :

[Lady_jade]

bonjour,

j'ai une petite question concernant les diagrammes de classes.
Je suis en train de modéliser en UML une base de données qui à donc un diagramme de classe. Cette BDD contiendra les infos de mon système.

Et j'ai un système que je veux développer en JAVA qui a aussi un diagramme de classe.

J'ai construit le diagramme de classe du système de façon identique au diagramme de classe de ma BDD. sauf que mon diagramme de classe du sytème contient des méthodes en plus.

Je voudrais savoir si mon raisonnement est le bon?

Quelqu'un pourrait-il me donner son avis?

Merci

[dlemoing]

Si tu veux un modèle objet avec des EJB prépare toi à avoir de grosses désillusions.
Tu souhaites vraiment utiliser des EJB ? Tu as des contraintes les imposant ? Tu veux faire ta correspondance avec des EJB Entity ? (évite ca de suite)
Si tu as une correspondance entre tes modèles objet et relationnels et que tu souhaites tirer profiter d'un vrai Domain Model, tourne toi vers des solutions ORM du type Toplink, Hibernate, ou JDO.

[Lady_jade]

Ah bon? pourquoi éviter les EJB?
Qu'est ce qui ne va pas avec eux?

En fait je développe un site web avec JSP, java et je voudrais séparer mes classes métiers de la présentation, donc les EJB me paraissaient être la bonne solution.

et donc lorsque j'ai modéliser mon système et ma BDD je me suis apperçue que j'avais sensiblement les mêmes diagrammes.
d'ou ma question de plus haut, ai-je fais un bon raisonnement?

merci

[dlemoing]

Notamment parceque les EJB se sont révélés être de vrai catastrophes en pratique :
- développement pénible
- testabilité
- cycle de développement long
- performances (parceque souvent mal utilisés)

Les EJB Entity sont pires que tout. Ils ne peuvent pas être utilisés pour décrire de VRAI Domain Model. Pas d'héritage, performances horribles en BMP sur les relations (problème n+1) et langage de requete limité pour CMP,... Tu trouveras plein de débats à ce sujet sur le net.

Si tu t'es contenté de lire la doc de Sun, effectivement, tu peux faire la confusion entre EJB et J2EE. Ce n'est heureusement pas vrai.
J2EE != EJB

Si tu souhaites vraiment utiliser les EJB, contente toi de travailler avec des EJB Session stateless et des Message Driven Bean.
Si tu veux faire la correspondance entre des objets (Domain Model) et ta base de données, la solution a un nom : ORM. Les outils pour cette solution sont Toplink, Hibernate ou JDO. Les EJB Entity ne sont pas une véritable solution ORM. Si tu ne penses pas te lancer dans cette solution ORM, tu peux toujours faire la correpondance en utilisant JDBC.
Quelque soit ton choix, définit une interface de DAO indépendante de la techno et écrit une implémentation qui utilisera la techno de ton choix.

PS : mes commentaires se font sur les versions des EJB allant jusqu'à 2.x

[ego]

En résumé :
- conserve tes classes Java "toutes simples" = des POJO (Plain Old Java Objects)
- utilise un framework comme Hibernate
- regardes le framework SPRING
- N'utilises les EJB que pour faire des Services distribués (EJB Session)

[dlemoing]

Je suis d'accord avec ego.
Quoique, Spring permet aussi la distribution d'objet avec différentes technos (RMI, JAX-RPC, ...).
Spring est fourni avec un certains nombre d'exemples qui te montreront que J2EE sans EJB c'est possible (et préférable).
Tu peux également télécharger les exemples du dernier livre (Professional Java Development with the Spring Framework) sur le sujet sur le site de Wrox.

[ndp]

salut,

J'ai construit le diagramme de classe du système de façon identique au diagramme de classe de ma BDD. sauf que mon diagramme de classe du sytème contient des méthodes en plus.

tu veux modeliser deux choses differentes: ton systeme d'un cote, et le schema de ta base de l'autre. Tu retrouvera surement des points communs (nom de table et nom de classe), mais je le repete, tu modelises deux choses differentes. Le mapping entre "objet" et "relation", n'est pas evident, et je rejoins les autres, sur leurs conseils.