Le contrôleur doit-il transmettre des données à une vue dans le modèle MVC?

Je travaille assez souvent avec ASP.NET MVC (et d'autres implémentations MVC basées sur le Web), mais c'est quelque chose dont je n'ai jamais été sûr: le contrôleur et la vue devraient-ils communiquer?

Bien sûr, le contrôleur devrait choisir la vue à utiliser, mais qu'est-ce que je veux dire, le contrôleur devrait-il transmettre des données à la vue? À mon avis, si la vue attend des données du contrôleur, elles sont effectivement liées ensemble en tant que paire (contrôleur, vue). Au lieu de cela, la vue communique généralement avec le modèle lui-même et est indépendante de tout contrôleur.

Ai-je la bonne approche, ou s'agit-il d'un cas où il n'y a pas une seule bonne réponse? La réponse change-t-elle lorsque vous travaillez sur le Web par rapport à d'autres environnements? La réponse change-t-elle lorsque vous avez le concept d'une vue fortement typée (comme dans ASP.NET MVC) ou non?

Le contrôleur prépare les données qui seront ensuite transmises à la vue pour le rendu / affichage. Il accepte également les données d'entrée des utilisateurs via un mécanisme de publication-abonnement ou similaire. Consultez le premier diagramme sur Wikipedia ou le site Web de Martin Fowler pour plus d'informations sur MVC.

si la vue attend des données du contrôleur, elles sont effectivement liées ensemble en tant que paire (contrôleur, vue).

Bien qu'une vue accepte généralement des données, dans la plupart des frameworks MVC, elle ne dépend pas de contrôleurs spécifiques. Les exceptions sont, par exemple, la famille JavaServer Faces. De manière générale, les frameworks tels que Rails, Django ou Spring MVC vous permettent de dissocier les vues des contrôleurs en passant des données (le contexte, généralement une carte / dictionnaire / sac) à une vue (où une vue est une implémentation du modèle de vue de modèle ).

La réponse change-t-elle lorsque vous avez le concept d'une vue fortement typée (comme dans ASP.NET MVC) ou non?

Que votre langage de programmation soit fortement typé n'a aucune influence sur la façon dont vous organisez votre application.

La question que vous soulevez est discutée de temps à autre dans mon équipe. Nous discutons de deux approches, qui ont leurs inconvénients et leurs avantages.

Le premier, fait valoir que le contrôleur peut mettre à jour la vue par le modèle suivant. Il écoute les événements de l'interface graphique et du modèle. Lorsqu'un événement GUI se produit, il exécute l'action requise dans le modèle, qui à son tour se déclenche et se déclenche. Maintenant, le contrôleur met généralement à jour la vue avec les données requises.

La deuxième approche, fait valoir que la vue elle-même écoute les événements du modèle et se met à jour avec les données qui sont attachées à l'événement ou en interrogeant le modèle.

Dans la première approche, vous avez plus de puissance sur le contrôleur qui contrôle vraiment tout ce qui se passe sur votre application. Le pouvoir de décider de quelle manière la vue doit être mise à jour en fonction de l'événement qui est entre ses mains et de cette façon, vous gardez votre vue pure. Cependant, comme vous l'avez dit, de cette façon, votre vue et votre contrôleur sont couplés.

Dans la seconde, vous les découplez, mais votre vue se contrôle en fait d'une certaine manière.