Modèle MVC global

Bonjour,

Ayant déjà utilisé le langage C# pour un projet au cours duquel j'ai essayé de respecter une architecture MVP (Model-View-Presenter), je me pose aujourd'hui une question à propos de la mise en oeuvre d'un modèle MVC dans un projet Qt.

Voici tout d'abord une réponse que j'ai trouvé sur un forum qui expliquerait bien la difficulté à utiliser ce pattern : (lien : http://stackoverflow.com/questions/5...ew-terminology)

Citation:

---

Qt's MVC only applies to one data structure. When talking about an MVC application you should not think about QAbstractItemModel or QListView.

If you want an MVC architecture for your whole program, Qt hasn't such a "huge" model/view framework.

---

Autrement dit, bien que les delegates permettent d'adopter une logique MVC (ou plutôt MVD) pour des composants d'une application, cette logique ne serait pas applicable à l'ensemble de l'application.

Par exemple, admettons qu'on ait besoin de connaître dans plusieurs composants un état qui peut être modifié par plusieurs d'entre eux, on passerait alors par exemple en paramètre de chaque constructeur de composant un "stateManager" avec une gestion d'événements (modèle discutable bien sûr).
Seulement, ce stateManager serait plutôt une part du modèle et donc ne devrait en aucun cas être connu par les vues directement (en C#, je passais par le presenter de chaque vue..).

Comment s'y prendre donc pour avoir dans son application Qt une logique globale de modèle MVC plutôt qu'une logique "locale" ?

Sinon, j'envisage d'utiliser à nouveau la logique MVP mais cette fois en Qt. Par contre, j'ai l'impression que cela ne se fait pas souvent. Après quelques recherches sur internet, il semblerait qu'utiliser MVP en Qt ne soit pas commun.

Merci :D

Salut,

De manière générale, les états font partie du modèle, mais leur utilisation fait partie soit de la vue, soit du contrôleur.

Ceci dit, il faut te méfier du terme "manager".

C'est en effet un terme beaucoup trop générique car il peut représenter plusieurs choses:

1. Le fait de créer des états, qui échoit, normalement, au contrôleur
2. Le fait de passer d'un état à un autre, qui échoit aussi normalement au contrôleur
3. Le fait d'utiliser les états, pour prendre des décisions diverses qui peut tout aussi bien échoir au contrôleur qu'à la vue

Enfin, il faut voir de quelle manière tes états vont avoir à travailler:
Vas tu avoir un ensemble reprenant chacun des états possibles, et te contenter de "prendre l'état correspondant" à chaque fois que le besoin s'en fait sentir ou vas tu au contraire "créer" l'état adéquat "sur demande":question:

Citation:

---

Ceci dit, il faut te méfier du terme "manager".

C'est en effet un terme beaucoup trop générique car il peut représenter plusieurs choses:
Le fait de créer des états, qui échoit, normalement, au contrôleur
Le fait de passer d'un état à un autre, qui échoit aussi normalement au contrôleur
Le fait d'utiliser les états, pour prendre des décisions diverses qui peut tout aussi bien échoir au contrôleur qu'à la vue

---

En fait je me sers du ContextManager comme un objet du modèle qui va récupérer les événements de changement d'état pour ensuite avertir tous les composants influencés par ce changement.
Or, dans le modèle MVC, j'imagine qu'un contrôleur est plutôt attaché à une classe. Il me fallait donc un élément à passer en paramètre de tous les constructeurs des composants, ou, plus précisément ici, à tous les presenters attachés à la vue de ces composants (modèle MVP).
Ainsi, c'est le presenter qui a connaissance du contextManager et qui met à jour la vue si besoin.

Ce qui m'embête aussi dans le modèle MVC, c'est que c'est le modèle qui met à jour la vue. Avec le pattern MVP, tout passe par l'intermédiaire du presenter et le modèle et la vue sont complètements indépendants, d'autant plus que le presenter a connaissance que des interfaces implémentées par la vue et le modèle.

Citation:

---

Enfin, il faut voir de quelle manière tes états vont avoir à travailler:
Vas tu avoir un ensemble reprenant chacun des états possibles, et te contenter de "prendre l'état correspondant" à chaque fois que le besoin s'en fait sentir ou vas tu au contraire "créer" l'état adéquat "sur demande"

---

Les états existent déjà initialement et seront juste manipulés pour définir un contexte de l'application.

Citation:

---

Envoyé par sfarc

En fait je me sers du ContextManager comme un objet du modèle qui va récupérer les événements de changement d'état pour ensuite avertir tous les composants influencés par ce changement.
Or, dans le modèle MVC, j'imagine qu'un contrôleur est plutôt attaché à une classe.

---

En fait, le controleur va faire le lien entre certaines classes.

Plus précisément, entre certaines règles "intrinsèques" (le "contrat" proposé par) la ou les classes qu'il gère et la situation actuelle.

Pour te permettre de comprendre, imaginons un jeu d'échec.

Il existe six sortes de pièces différentes (pion, tour, cavalier, fou, dame et roi) qui peuvent toutes être considérée comme... de pièces.

De manière générale, une pièce (quelle qu'en soit la sorte) peut se déplacer vers une nouvelle position: cela fait partie des services que tu es parfaitement en droit d'attendre de la part de n'importe quelle pièce et correspond à une fonction fort proche de moveTo(Position)

Seulement, de manière particulière, un pion, un fou ou un cavalier ne peuvent pas se déplacer de la même manière: un pion ne peut se déplacer qu'en ligne droite, alors qu'un fou ne peut le faire qu'en diagonale et un cavalier en "L".

Tu pourrais donc déjà très bien créer un contrôleur qui vérifie pour toute pièce (sans précision) si un déplacement vers une position particulière est autorisé pour le type particulier de la pièce.

Ainsi, si la pièce envisagée est un fou et que la position vers laquelle tu voudrais le déplacer n'est pas dans les diagonales par rapport à sa position actuelle, tu peux, dés le départ, interdire le déplacement, parce que cela ne correspond pas à un déplacement potentiellement autorisé pour le fou.

Ensuite, il y a une autre règle qui dit que ton déplacement devra s'arrêter au plus tard sur la première case occupée que tu rencontreras:

• sur la case en question si elle est occupée par une pièce de l'adversaire
• sur la case précédente si la case est occupée par une pièce de ta propre équipe

Tu pourras donc créer un autre contrôleur, qui travaillera toujours avec une pièce (sans d'avantage de précision) mais qui aura en plus connaissance de toutes les pièces sur l'échiquier et qui s'assurera que la pièce que tu déplace s'arrête bel et bien au plus tard sur la première case occupée qu'elle rencontre.

Si le deux conditions sont remplies (c'est un mouvement autorisé pour la sorte de pièce envisagée ET je ne passe pas au dessus d'une autre pièce), le controleur peut alors décider de déplacer la pièce et faire en sorte de signifier ce déplacement "à tout objet intéressé par la modification", en ce, y compris à la vue qui doit représenter la situation actuelle ;)

Citation:

---

Il me fallait donc un élément à passer en paramètre de tous les constructeurs des composants, ou, plus précisément ici, à tous les presenters attachés à la vue de ces composants (modèle MVP).
Ainsi, c'est le presenter qui a connaissance du contextManager et qui met à jour la vue si besoin.

---

En fait, le contrôleur est plus "à double sens":

Il reçoit des informations issues de la vue afin (si les conditions sont remplies) de modifier le modèle, puis indique (si besoin) à la vue qu'il est temps de se mettre à jour ;)

Citation:

---

Ce qui m'embête aussi dans le modèle MVC, c'est que c'est le modèle qui met à jour la vue. Avec le pattern MVP, tout passe par l'intermédiaire du presenter et le modèle et la vue sont complètements indépendants, d'autant plus que le presenter a connaissance que des interfaces implémentées par la vue et le modèle.

---

En fait, la vue dépend du modèle (il faut bien qu'elle dispose des informations à afficher :D ), mais le modèle n'a absolument aucun besoin de connaitre la vue: Les données métiers sont ce qu'elles sont et sont manipulées par le contrôleur ;)

Citation:

---

Les états existent déjà initialement et seront juste manipulés pour définir un contexte de l'application.

---

Tu auras donc, au niveau du métier (du modèle), une classe qui maintient tes différents états et qui permet leur manipulation "naïve" (comprends: sans forcément prendre en compte les restrictions de circonstances), mais que je te conseillerais de nommer différemment que "Manager" :D, et un (ou plusieurs) contrôleur(s) qui prendraient en compte les règles qui ne dépendent pas exclusivement des différents états.

Ce (ces) contrôleur(s) réagiraient sans doute (entre autres) à certains événements issus de la (des) vue(s) et, le cas échéant, indiqueront à la (aux) vue(s) qu'il est temps de se mettre à jour ;)

Ok je vois, merci Koala01 pour toutes ces explications ;).

Tes conseils m'amènent tout de même à te poser une question. Tu sembles préférer le modèle MVC, que penses-tu du modèle MVP ?

Je pourrais suivre la même logique avec le modèle MVP avec le contrôleur qui aurait à peu près le même rôle que le contrôleur sauf que la vue n'aurait pas connaissance du modèle et que se serait au presenter de mettre à jour la vue par le biais de son interface au lieu que le contrôleur envoie un événement de mise à jour à la vue pour que celle-ci appelle alors le nouveau modèle...

En fait, je ne me suis jamais vraiment intéressé au principe du modèle vue présenteur :aie:

Mais je crois que l'on parle de présenteur, de contrôleur ou de délégué, le principe reste finalement fort similaire, et se base à chaque fois sur la même phrase de David Wheeler

Citation:

---

Envoyé par David Wheeler

all problems in computer science can be solved by another level of indirection

---

L'idée reste en effet toujours de "placer" entre la vue et la partie métier un "système" qui permettra à la vue de ne pas avoir la responsabilité, en plus d'afficher les donnée et de transmettre les ordres de l'utilisateur, d'aller modifier effectivement les données métier ;)

Citation:

---

Envoyé par David Wheeler
all problems in computer science can be solved by another level of indirection

---

Bien dit! :P Merci pour la référence ;)

Je pense avoir les idées un peu plus clair. Je devrais pouvoir faire un application globale avec un patron MVC ou MVP en Qt avec un peu de réflexion!

Merci encore Koala01!:D