Discussion :

[dahtah]

Bonjour à tous,
Comment effectuer la communication entre Vue et Modèle, quand le modèle est subdivisé en de nombreuses sous-classes? Dans tous les exemples MVC que j'ai lu (en C# du moins), la classe modèle est instanciée directement dans la vue afin d'y joindre les évènements. Mais si les évènements sont dispatchés dans plusieurs classes du modèle comment fait-on? On ne va pas instancier toutes les classes...
Dans le tutoriel MVC de Baptiste Witch, la Vue n'a pas accès à l'instance de la classe modèle qu'elle représente.
Merci...

[Hephaistos007]

La notion de Vue, de Modèle et de communication V<-->M sont des abstractions volontaires qui masquent en fait de nombreuses sous-entités et sous-associations.
On sait que la vue est à l'écoute du modèle. Donc, certaines classes qui forment la Vue devront s'enregistrer comme observateurs de certaines autres classes qui forment le modèle.
Il n'y a pas de recette magique, tu es le seul à savoir ce qui forme la Vue, le Modèle et les relations V<-->M dignes d'un intérêt dans ton cas.

Petite explication (théorique)
Les design patterns s'expriment au niveau des classes et peuvent donc être suivis "à la lettre" lors de l'élaboration d'un modèle de classe (que ce soit haut-niveau avec UML ou bas-niveau avec Java par exemple). En revanche, le MVC est un architectural pattern. Dans ce type de pattern, le bloc de construction de référence est le composant plutôt que la classe. Or un composant c'est une unité à "gros-grain" c-a-d une abstraction d'une multitude de classes quelconques. On ne peut donc pas traduire tel quel un pattern architectural vers un modèle de classe car il y a un fossé d'abstraction. Tout repose sur l'expérience et le savoir faire du praticien ! Dans l'exemple du MVC, le composant M pourra correspondre à des milliers de classes (idem pour V et le C). Pareillement, l'unique relation qui lie un composant M à un composant V pourra être en réalité constitué de centaines d'associations entre les classes concernées. C'est là toute la perversité des architectural patterns : ils véhiculent des idées très puissantes mais ne disent pas grand chose sur leur mise en oeuvre pratique.

[dahtah]

Merci de ta réponse.
Le seul truc qui me pose problème en fait, c'est l'organisation de ma couche Modèle. J'ai mis en place le pattern Observer qui fonctionne parfaitement, et j'ai crée une interface qui rend le controleur quasi indépendant de la vue.
Mais est-ce que quelqu'un pourrai juste mettre un exemple de l'organisation de la couche modèle, ne serait-ce qu'avec deux classes? Tous les tutoriels ne mettent en place qu'une classe modèle, ce qui rend difficile l'extension du pattern.
Merci...

[hed62]

Tu peux faire un "Photograph" comme on appele ca ici :

Une super classe Model qui possède une instance de toutes tes classes modèle plus petites. Ce Photograph propose aussi un accès direct à toutes les propriétés (en lecture) de ton arbre de petits Modele.

Ainsi, tu restreint à la lecture seule, tu accède aux informations en maxi 2 navigations (et donc si l'organisation change, seul le photograph change)

Et pour l'ecriture, tu passe par ton(tes) controllers qui accèdent directement au bon 'petit' Model

[dahtah]

Une super classe Model qui possède une instance de toutes tes classes modèle plus petites. Ce Photograph propose aussi un accès direct à toutes les propriétés (en lecture) de ton arbre de petits Modele.

Excellent.... et tout simple.
Merci