Model-View-Controller: L'utilisateur interagit-il avec la vue ou avec le contrôleur?
J'ai récemment découvert le modèle de conception MVC. J'apprends du livre Head First Design Pattern.
Selon ce livre (si je comprends bien):
Le modèle est la plupart de la logique et des données d'application.
The View est fondamentalement l'interface graphique qui représente visuellement le modèle à l'utilisateur.
Le contrôleur est responsable de la "médiation" et agit comme un "intermédiaire" entre la vue et le modèle. La vue signale au contrôleur que l'utilisateur a effectué une action et le contrôleur la traduit en appels de méthode sur le modèle.
Cependant, beaucoup d'endroits sur le Web contredisent ce que je comprends de ce livre. Ils prétendent que généralement l'utilisateur interagit avec le contrôleur, pas la vue.
Laquelle est vraie ou plus courante? L'utilisateur interagit-il directement avec le contrôleur ou directement avec la vue? Les deux approches sont-elles acceptables? Quel est le plus courant?
L'utilisateur interagit avec la vue , mais la vue doit communiquer les actions au contrôleur . Le contrôleur peut mettre à jour le modèle , mais il n'est pas requis avec chaque/tout changement.
La description que je fournis est basée sur mon expérience personnelle avec l'implémentation .NET de MVC. Votre implémentation peut être différente.
Le contrôleur est l'endroit où les actions sont traitées, essentiellement une couche de gestion. Un simple contrôleur ne fera rien de plus que d'obtenir les données du modèle pour les alimenter dans la vue. Un contrôleur compliqué effectuera toutes sortes d'actions, jusqu'à la gestion de la sécurité, l'authentification, l'autorisation, l'enregistrement et peut-être bien d'autres choses.
La vue ne doit être responsable que de l'affichage des informations d'une manière que l'utilisateur peut comprendre. Il peut y avoir un croisement ici avec le contrôleur et le modèle car des choses comme les applications à page unique (SPA) auront des commentaires de validation des données pour l'utilisateur. Tout autre croisement est fortement désapprouvé.
Le modèle traite les données. Cela comprend la validation des données (le cas échéant). Le stockage et la récupération des données sont également gérés dans cette couche.
[~ # ~] mise à jour [~ # ~]
Il semble y avoir une certaine confusion autour de qui fait quoi et quand. J'ai inclus deux aperçus différents des architectures MVC car elles sont similaires, mais pas les mêmes. Il y a place pour l'une ou l'autre interprétation. Peut-être beaucoup plus. Les descriptions ci-dessus sont mon interprétation de MVC à partir de plusieurs sources, y compris ma propre expérience dans la création d'applications utilisant cette méthodologie. Espérons que cette mise à jour contribuera à dissiper une partie de cette confusion.
MVC est une tentative de construction d'un modèle de conception séparation des préoccupations pour le développement de logiciels. Il a été principalement implémenté dans des applications Web (à ma connaissance).
La vue gère toutes les interactions de l'utilisateur. Si votre utilisateur clique sur un bouton, la vue détermine si le clic est une interaction de l'interface utilisateur ou quelque chose qui est au-delà de sa préoccupation (une interaction du contrôleur). Si le bouton fait quelque chose comme copier des valeurs d'un champ à un autre, votre implémentation déterminera s'il s'agit d'un problème de vue ou d'un problème de contrôleur. Vous n'aurez probablement ce flou de préoccupations que lorsqu'il s'agit d'une application de page unique (SPA).
Le contrôleur est l'endroit où vos actions sont traitées. La vue a communiqué que l'utilisateur a décidé de modifier les valeurs de certains champs. Le contrôleur peut effectuer la validation de ces données ou elles peuvent être traitées par le modèle. Encore une fois, cela dépend de la mise en œuvre. Si le contrôleur possède des fonctions de sécurité, il peut déterminer que l'utilisateur ne dispose pas de privilèges suffisants pour effectuer l'action. Il rejetterait les modifications et mettrait à jour la vue en conséquence. Le contrôleur détermine également les données à récupérer du modèle, comment les empaqueter et mettre à jour la vue avec ces données.
Le modèle détermine comment et où stocker les données. Il peut également effectuer la validation de ces données avant de les stocker (il devrait le faire car les gens contourneront la vue à l'occasion).
Wikipedia a un article sur MVC .
- Un modèle notifie sa ou ses vues et contrôleurs associés en cas de changement d'état. Cette notification permet aux vues de mettre à jour leur présentation et aux contrôleurs de modifier l'ensemble de commandes disponible. Dans certains cas, une implémentation MVC peut plutôt être "passive", de sorte que d'autres composants doivent interroger le modèle pour les mises à jour plutôt que d'être notifiés.
- Une vue reçoit du contrôleur toutes les informations dont il a besoin pour générer une représentation de sortie pour l'utilisateur. Il peut également fournir des mécanismes génériques pour informer le contrôleur des entrées utilisateur.
- Un contrôleur peut envoyer des commandes au modèle pour mettre à jour l'état du modèle (par exemple, éditer un document). Il peut également envoyer des commandes à sa vue associée pour modifier la présentation de la vue du modèle (par exemple, en faisant défiler un document).
De la vue d'ensemble de Microsoft sur MVC .
Modèles. Les objets de modèle sont les parties de l'application qui implémentent la logique du domaine de données de l'application. Souvent, les objets de modèle récupèrent et stockent l'état du modèle dans une base de données. Par exemple, un objet Product peut récupérer des informations dans une base de données, opérer dessus, puis réécrire les informations mises à jour dans une table Products dans une base de données SQL Server.
Dans les petites applications, le modèle est souvent une séparation conceptuelle au lieu d'une séparation physique. Par exemple, si l'application lit uniquement un ensemble de données et l'envoie à la vue, l'application n'a pas de couche de modèle physique et de classes associées. Dans ce cas, l'ensemble de données joue le rôle d'un objet modèle.
Vues. Les vues sont les composants qui affichent l'interface utilisateur (UI) de l'application. En général, cette interface utilisateur est créée à partir des données du modèle. Un exemple serait une vue d'édition d'une table Produits qui affiche des zones de texte, des listes déroulantes et des cases à cocher en fonction de l'état actuel d'un objet Produit.
Contrôleurs. Les contrôleurs sont les composants qui gèrent l'interaction utilisateur, travaillent avec le modèle et sélectionnent finalement une vue à rendre qui affiche l'interface utilisateur. Dans une application MVC, la vue affiche uniquement des informations; le contrôleur gère et réagit à l'entrée et à l'interaction de l'utilisateur. Par exemple, le contrôleur gère les valeurs de chaîne de requête et transmet ces valeurs au modèle, qui à son tour peut utiliser ces valeurs pour interroger la base de données.
L'utilisateur interagit avec le contrôleur . Du point de vue technique, vous n'interagissez pas avec la vue , vous êtes juste en utilisant pour interagir avec le contrôleur .
En surface, il semble que l'utilisateur interagisse avec l'interface graphique - également pour un non-programmeur, cela a plus de sens, mais en cliquant sur un bouton, vous parlez essentiellement au contrôleur pas la vue .
De plus, toutes les applications - même les applications Web MVC, n'ont pas d'interface graphique. Vous pouvez interagir avec le contrôleur via une API - simplement simple url-routes par exemple, placé dans le contrôleur lui-même.
Le contrôleur doit être l'endroit où reçoit et Gère les demandes de l'utilisateur. Donc, si vous accédez en quelque sorte au modèle directement à partir de Voir - peu importe comment, alors ce n'est plus [~ # ~] mvc [~ # ~] plus.
Prenons un exemple concret de la raison pour laquelle les utilisateurs interagissent directement avec les vues et non avec les contrôleurs.
Dans l'application musicale de l'iPhone, une fonction de haut niveau consiste à lire une liste de lecture. "Lire une liste de lecture" est une fonction d'un contrôleur de l'application.
Il existe plusieurs façons d'activer cette fonction. Je peux cliquer sur la liste de lecture à l'intérieur de l'application, ou je peux demander à Siri (interface vocale) d'exécuter la même fonction. Ce sont deux gestes différents qui sont reconnus par les différentes vues.
Les commentaires dans chaque vue sont également différents. Siri vous dira qu'il joue la musique que vous avez demandée. L'application musicale vous montrera un retour visuel indiquant qu'elle joue la playlist.