Discussion :

[alves.seb]

Je me permet de vous écrire pour vous demander quelques petits conseils sur un projet web (projet scolaire) que je doit réaliser.
Ci-joint vous trouverez le diagramme de classe du projet qui me pose quelques intérrogations.
Pour information je vous rappelle briévement le sujet :
- L’objectif de ce site Internet est de pouvoir mettre en ligne des articles (texte et vidéo) gratuitement pour aidé les développeurs. Le principe de ce site est de pouvoir à n’importe qui, enregistré sur le site, de déposer un article lié à une catégorie (Java,Php,Delphi etc…). Sur le site on peut distinguer cinq types de personnes, les membres, les auteurs, les relecteurs, les responsables rubrique et enfin les administrateurs.


Aprés une étude des cas d'utilisation nous avons réaliser le diagramme conceptuel ci-joint, j'aimerais donc avoir votre avis sur ce diagramme de classe.Cependant il reste cependant des points que je n'arrive pas à modéliser.

1er point : C'est l'administrateur qui gére les membre du site, donc modification supression etc ..., l'ajout se fait au moment de l'inscription d'un membre sur le site. Ou doit-on d'aprés vous placer les méthode de création, modification,suppression de membre et getListMembre (dans la classe membre ???, en rajoutant une association entre administrateur et membre ???, en créant une nouvelle classe qui gére ces opérations ...).

2éme point : il en est de même que pour le 1er point, sachant que s'est l'administrateur qui gére les rubriques du site, ou doit-on d'aprés vous placer les méthodes de création, modification et suppression de rubrique.

Merci pour votre aide.

Seb

[ego]

Mon expérience m'a montré que dans ton type de situation, il est préférable de clairement distinguer les données et les traitements (oui, même en objet).
Donc pour répondre à tes questions, je ferai des classes dédiées.
Une remarque sinon sur ton modèle. Ce n'est pas parce qu'un rôle a le droit de faire une action qu'il faut mettre cette action comme méthode de la classe représentant le rôle. Encore une fois, il est préférable de séparer les classes "rôles" des actions que ces rôles peuvent réaliser.

[alves.seb]

Merci pour ta réponse.
Tu dis que tu ferais des classes dédiées, s'est à dire, des classes pour le traitement et des classes pour les données du systéme ?? Si s'est s'est la cas pourrais me donné un petit exemple concret, par exemple pour les gestions des membres du sites.
Je suppose que quand tu parle de séparer les classes "rôles" des actions, cela reviens à dire qu'il n'est pas nécessaire de mettre des méthodes comme ajoutXX dans ces classes "rôles" mais plutôt dans des classes séparées. Cela veut dire quand peut envisager de crée un classe gestionMembres (avec des méthodes getListMemebre, supprimer membres, etc ...)dans un package 'traitement' du projet ??
Si je découpe mon projet en package, j'aurais un package traitement et un package modéle. Alors ma derniére question est simple, est-ce que tout les élements du package modéle doit se retrouver en base de donnée si on décide d'utiliser une base ou uniquement les élements qui nous semble pertinent ??

Merci pour votre aide.

Seb

Nb: quelques petits exemples seront les bienvenue.

[alves.seb]

Juste pour info je vous joint un petit diagramme de classe qui n'est évidement pas complet et qui reprend les idées de ego. J'aimerais avoir votre avis sur ce nouveau schéma. Schéma qui reprend le modéle MVC.

Merci.
Seb.

[ego]

perso, ce second modèle me parait mieux
Pour la persistance des classes "données", c'est à toi de voir ce qu'il faut stocker. Dans un modèle de classes "données", il peut y avoir effectivement des données non persistantes. Mais peut être que l'on mettra ces données dans un package à part. Ces données non persistantes sont par exemple des données appellées "Value Object" ou encore des données transitoires permettant des calculs ou des classements d'objets pour des besoins d'algorithmie, de cache,...

[alves.seb]

Merci beaucoup pour tes conseils.
Pour toi ce modéle te parait beaucoup mieux, cela veut dire que dans les classes qui se trouve dans le package 'data' il n'y aurais que des méthodes de getter et de setter ?? Dans ce cas tout les accés à la base de donnée se ferais dans les classes de traitement ??
J'ai effectué un diagramme de cas d'utilisation et je me demande tout de même si toute les méhodes lié à ces cas d'utilisations doivent se retrouvé dans la partie traitement ??

[ego]

les données ne doivent contenir que des get/set et éventuellement des méthodes qui ne manipulent que les attributs de l'objet lui-même (ses attributs + ses associations) mais pas plus.
Les accès à la base se font au travers de classes dites "DAO"
Au final on a souvent :

- DonneeX
- DonneeXServices
- DonneeXDAO

[jc63]

bonjour,

Je me pose en fait un peu les mêmes questions que toi. pour le découpage de l'application je suis tombé sur la même structure que toi (pour mon application) metier - service - dao - vue. Je me suis inspiré d'une application exemple d'un bon bouquin sur Spring http://tudu.sourceforge.net/.
sinon je suis un peu bloqué pour le passage à la base de données. je ne sais pas quelle est la bonne solution pour représenter l'héritage. Faut-il avoir la même structure que pour les classes. Dans ton cas par exemple, as-tu créer une table membre relié à des tables administrateur, auteur ou as-tu seulement des tables pour les classes enfants et non opur la classe membre. (Dans ton cas comme tu n'as pas l'air d'avoir d'attributs spécifiques pour les classes enfants tu as du prendre la 2 éme solution)

Je ne sais pas si tu en ai à ce niveau et si tu as été confronté aux mêmes problèmes que moi mais si c'est le cas peux-tu (si tu as le temps) me faire partager même rapidement ton expèrience.

merci d'avance, Julien C.

[ego]

Toutes les solutions sont possibles. C'est une histoire de compromis entre évolutivité, performance, et contraintes d'intégrité implémentées en base ou non.

Si tu as une table par classe de la hiérarchie, c'est plus évolutif et tu pourras mettre toutes les contraintes que tu veux.
Si tu as une table uniquement pour les classes filles, c'est un peu moins évolutif mais plus performant que le cas précédent pour certaines requêtes. Les contraintes qui pourraient découler des relations exitantes au niveau de la classe mère risquent de ne pas pouvoir être implémentées totalement en base.
Si tu as une seule table pour toute la hiérarchie, c'est pas évolutif mais certaines requêtes sur l'ensemble de la hiérarchie seront rapides. Pour les contraintes, là c'est la solution la plus nulle.

Le cas classique est je pense le cas où on a une table par classe fille.

[jc63]

ok merci pour ta réponse. J'ai décidé d'utiliser une table par classe fille. Avec Hibernate j'ai vu que c'était assez simple à implémenter. je vais tester ça.

merci.