[Article] Variations sur le modèle MVC

Bonjour à tous,
je viens de terminer la rédaction d'un article portant sur le modèle MVC et ses dérivés.
Vous pouvez réagir sur ce fil.

Bonne lecture !

Bonjour,
Je viens de parcourir l'article sans entrer dans les détails. Je crois que c'est toujours une bonne idée de faire des synthèses sur des sujets qui offrent des variations comme le MVC. Mais je regrette déjà ce que j'ai signalé dans un message sur le MVC : tous les tutoriels partent du niveau "zéro" : le modèle proposé est trop simple (simpliste ?), donc ne prête pas vraiment à discussion. Il y a deux vues, mais ça n'est pas ça qui pose problème en général (par contre ça permet de voir la puissance du MVC à ce niveau, ce qui est une bonne chose). Par contre la discussion sur le rôle du contrôleur est une bonne chose :ccool:.

Je trouve dommage qu'il n'y a jamais d'exemple où l'on présente une "vraie" application, avec des boutons qui n'agissent pas directement sur le modèle, avec des menus qui présentent des boîtes de dialogue intermédiaires qui peuvent aboutir ou non à une modification du modèle, etc. Je pense que celui qui réalisera un tutoriel sur l'application du MVC à une application un peu "élaborée" fera progresser vraiment beaucoup de monde (tous ceux qui ont lu plusieurs fois les mêmes exemples dans les tutoriels de base).

Exemple de cahier des charges sur un sujet que tout le monde connaît : le "paint" (ou le xfig pour les linuxiens) de base. C'est-à-dire : une fenêtre avec un menu (un seul...) à deux items : "open" et "ajouter une forme" ; une palette d'objets qui représentent : un carré, un cercle (ça suffit) ; une palette de mise en forme avec : changer couleur, effacer (ça suffit également) ; une surface de dessin... Plus compliqué c'est pas plus mal (niveau 3 :mouarf: ?), mais pas nécessaire. Déjà on aurait quelque chose d'un peu plus conséquent et on pourrait réfléchir dessus et en discuter.

Mais pour ne pas non plus exagérer, je remercie tout de même les auteurs des tutoriels existants pour leurs efforts et pour leur aide, et en particulier celui-ci :ccool:.

Bonjour totojava,
Je prends note de ta remarque. En effet, il est toujours assez frustrant de ne pas trouver des exemples plus conséquents que ceux présentés dans les tutoriels MVC.
Dans celui-ci, ma démarche est de présenter des variantes du MVC, et le rôle des entités au sein de l'architecture. L'exemple est un prétexte permettant de ne pas tomber dans un cours théorique. On m'a en effet fait la remarque lors de la relecture technique. J'ai souhaité rester dans un cadre simple, sans rentrer dans des détails trop complexes (la taille de l'article aurait aussi été plus conséquente).
Pour entrer plus dans les détails, je pense que je pourrais écrire une série de tutoriels autour d'une telle application en utilisant tour à tour les différents modèles, cette fois avec du code.

Merci de ton retour.

Bonjour,

Tout d'abord merci pour cet article très intéressant. Je connaissais que le modèle MVC de base et je me suis toujours demandé pourquoi le contrôleur avait la responsabilité de relayer les interactions de l'utilisateur mais c'était sans connaitre l'historique des anciens widgets qui n'avaient pas la possibilité de le faire. Du coup, je me demandais comment l'utilisateur interagissait avec le modèle MVC et notamment pourquoi il n'avait pas accès à la vue. Les diagrammes collaboratifs apportent les réponses :ccool:

Si j'ai bien compris, à chaque fois que la fonction update() apparait dans les diagrammes, cela fait référence au pattern Observer permettant ainsi un couplage faible entre les classes. Imaginons un cas plus concret, dans lequel le modèle aurait une multitude de propriétés. Comment procède-t-on pour la notification ? Sachant que le changement d'une seule propriété du modèle engage le déclenchement de l'update() mais l'observer ne sait pas quelle propriété à changé. Il est seulement notifié que le modèle à changé ce qui n'est pas top au niveau optimisation car il est obligé de faire une mise à jour complète du modèle. Comment faire pour que l'observer soit notifié d'un événement PropertyChanged et non d'un ModelChanged ?

Un début de réponse semble être apporté en conclusion au niveau du Presentation Model. Cependant, j'aurais aimé avoir plus d'information sur l'implémentation de ce mécanisme d'une manière générique.

D'avance merci ;)

Les outils de binding utilisent un PropertyChanged qui permet de notifier de manière générique le changement, en passant en paramètre le nom de la propriété. Les "update" simples notifient un changement global ou le changement d'une seule propriété, il est de la responsabilité de l'observateur de savoir reconnaître ce qui a changé.

Bonjour,

Article très intéressant qui permet de rendre moins mystérieux les concepts liés au MVC. Pour ma part, il m'a permis de me rendre compte que l'adaptation que j'avais faite de ce modèle était en fait un MVP.

Cependant, et un peu comme les commentaires précédents, il serait encore mieux d'avoir un exemple de chacun de ses modèles sur un cas plus complexe afin de pouvoir se rendre compte des problèmes rencontrés dans la "vrai vie".

Ensuite, on dit souvent, que le MVC est le composé de 3 patterns qui sont "Observer", "Strategy", et "Composite". Qu'en est-il de ces Pattern vis à vie des autres modèles évoqués dans l'article ? Bref, j'aurais aimé un peu plus de détail à ce sujet, mais encore une fois, sans un cas concret un peu plus complexe et un exemple d'implémentation je conçois qu'il soit difficile de les mettre en évidence.

Mis à part ça c'est du tout bon, et j'irais jusqu'à dire que c'est un des meilleurs articles du web sur la famille MVC. Cet article, une fois complétés par les diverses suggestions, pose pour moi les bases d'un article référence sur le sujet.

Bon travail,
Ciao

Félicitation au rédacteur de ce tuto!

Un peu comme ça a été dit précédemment, une tonne de tuto existe mais ne reflète pas forcément ce qui se fait aujourd'hui (Et oui! Même 5 ans après la rédaction de ce tuto... :-). Du coup ça fait du bien de resituer ce pattern dans le contexte d'aujourd'hui.

L'une des bases du MVC (que l'on retrouve dans tous les tutos) est que le contrôleur reçoit les événements utilisateurs... Mais pour quelqu'un comme qui développe des applications C++ avec des framework GUI telle que Juce, Qt, wxWidget, il est difficile de comprendre pourquoi ces interactions utilisateurs ne passent pas d'abord par la vue. Mais Enfffffffffffffffffffffiiiiiiiiiiiiiiiiiiin une explication claire! C'était tout bête: il s'agissait en effet des widget des années 80 qui ignoraient les évènements souris/clavier! Et ça on ne peut pas le deviner tout seul, mais ça change tout, vraiment tout! Donc encore un grand merci pour ce tuto!

Sinon, +1 pour avoir enfin un exemple de MVC dans le cas d'une vrai application avec un workflow plus compliqué (en gros contenant une machine à état...)