Le problème MVCest que les gens pensent que la vue, le contrôleur et le modèle doivent être aussi indépendants que possible l'un de l'autre. Ils ne le voient pas - une vue et un contrôleur sont souvent étroitement liés - le considérer comme M(VC).
Le contrôleur est le mécanisme d'entrée de l'interface utilisateur, qui est souvent emmêlé dans la vue, en particulier avec les interfaces graphiques. Néanmoins, la vue est sortie et le contrôleur est entré. Une vue peut souvent fonctionner sans contrôleur correspondant, mais un contrôleur est généralement beaucoup moins utile sans vue. Les contrôleurs conviviaux utilisent la vue pour interpréter les entrées de l'utilisateur d'une manière plus significative et intuitive. C'est ce qui rend difficile la séparation du concept de contrôleur de la vue.
Pensez à un robot radiocommandé sur un champ de détection dans une boîte scellée comme modèle.
Le modèle est tout au sujet des transitions d'état et d'état sans concept de sortie (affichage) ou de ce qui déclenche les transitions d'état. Je peux obtenir la position du robot sur le terrain et le robot sait comment faire la transition de position (faire un pas en avant / arrière / gauche / droite. Facile à visualiser sans vue ni contrôleur, mais ne fait rien d'utile
Pensez à une vue sans contrôleur, par exemple quelqu'un dans une autre pièce sur le réseau dans une autre pièce regardant la position du robot sous forme de coordonnées (x, y) en continu sur une console de défilement. Cette vue affiche simplement l'état du modèle, mais ce type n'a pas de contrôleur. Encore une fois, il est facile d'envisager cette vue sans contrôleur.
Pensez à un contrôleur sans vue, par exemple quelqu'un enfermé dans un placard avec le contrôleur radio réglé sur la fréquence du robot. Ce contrôleur envoie une entrée et provoque des transitions d'état sans aucune idée de ce qu'il fait au modèle (le cas échéant). Facile à imaginer, mais pas vraiment utile sans une sorte de retour de la vue.
La plupart des interfaces utilisateur conviviales coordonnent la vue avec le contrôleur pour fournir une interface utilisateur plus intuitive. Par exemple, imaginez une vue / contrôleur avec un écran tactile montrant la position actuelle du robot en 2-D et permettant à l'utilisateur de toucher le point sur l'écran qui se trouve juste devant le robot. Le contrôleur a besoin de détails sur la vue, par exemple la position et l'échelle de la fenêtre, et la position des pixels du point touché par rapport à la position des pixels du robot sur l'écran) pour interpréter cela correctement (contrairement au gars enfermé dans le placard avec le contrôleur radio).
Ai-je déjà répondu à votre question? :-)
Le contrôleur est tout ce qui prend l'entrée de l'utilisateur qui est utilisé pour amener le modèle à l'état de transition. Essayez de garder la vue et le contrôleur séparés, mais réalisez qu'ils sont souvent interdépendants l'un de l'autre, donc ce n'est pas grave si la frontière entre eux est floue, c'est-à-dire que la vue et le contrôleur sous forme de packages séparés peuvent ne pas être aussi clairement séparés que vous le feriez comme, mais ça va. Vous devrez peut-être accepter que le contrôleur ne soit pas clairement séparé de la vue car la vue est du modèle.
... une validation, etc. doit-elle être effectuée dans le contrôleur? Si tel est le cas, comment puis-je renvoyer les messages d'erreur à la vue - est-ce que cela doit passer à nouveau par le modèle ou le contrôleur doit-il simplement les renvoyer directement à la vue?
Si la validation est effectuée dans la vue, que dois-je mettre dans le contrôleur?
Je dis qu'une vue et un contrôleur liés doivent interagir librement sans passer par le modèle. Le contrôleur prend les entrées de l'utilisateur et doit effectuer la validation (peut-être en utilisant les informations du modèle et / ou de la vue), mais si la validation échoue, le contrôleur devrait être en mesure de mettre à jour directement sa vue associée (par exemple, message d'erreur).
Le test acide pour cela consiste à se demander si une vue indépendante (c'est-à-dire le gars dans l'autre pièce qui surveille la position du robot via le réseau) devrait voir quelque chose ou non à la suite d'une erreur de validation de quelqu'un d'autre (par exemple, le gars dans le placard a essayé de dire au robot de sortir du terrain). Généralement, la réponse est non - l'erreur de validation a empêché la transition d'état. S'il n'y a pas eu de transition d'état (le robot n'a pas bougé), il n'est pas nécessaire de dire les autres vues. Le gars dans le placard n'a tout simplement pas reçu de commentaires indiquant qu'il avait tenté de provoquer une transition illégale (pas de vue - mauvaise interface utilisateur), et personne d'autre n'a besoin de le savoir.
Si le gars avec l'écran tactile a essayé d'envoyer le robot hors du terrain, il a reçu un joli message convivial lui demandant de ne pas tuer le robot en l'envoyant hors du champ de détection, mais encore une fois, personne d'autre n'a besoin de le savoir.
Si d' autres vues ne devez savoir sur ces erreurs, vous dites effectivement que les entrées de l'utilisateur et les erreurs qui en résultent sont une partie du modèle et l'ensemble est un peu plus compliqué ...