Qu'est-ce que MVC, vraiment?

En tant que programmeur sérieux, comment répondez-vous à la question Qu'est-ce que MVC?

Dans mon esprit, MVC est une sorte de sujet nébuleux - et pour cette raison, si votre auditoire est un apprenant, vous êtes libre de le décrire en termes généraux qui ne risquent pas de susciter la controverse.

Toutefois, si vous vous adressez à un public averti, en particulier à un intervieweur, j'ai du mal à penser à une direction à suivre qui ne risque pas une réaction du type "eh bien, ce n'est pas correct! ...". Nous avons tous une expérience différente du monde réel et je n'ai pas vraiment rencontré le même modèle d'implémentation MVC à deux reprises.

Plus précisément, il semble y avoir des désaccords concernant la rigueur, la définition des composants, la séparation des pièces (quelle pièce convient où), etc.

Alors, comment devrais-je expliquer MVC de manière correcte, concise et sans controverse?

MVC est une architecture logicielle - la structure du système - qui sépare la logique domaine / application / entreprise (selon vos préférences) du reste de l'interface utilisateur. Pour ce faire, l'application est divisée en trois parties: le modèle, la vue et le contrôleur.

Le modèle gère les comportements fondamentaux et les données de l'application. Il peut répondre aux demandes d’informations, répondre aux instructions pour changer l’état de ses informations et même avertir les observateurs dans les systèmes événementiels lorsque les informations changent. Cela peut être une base de données, ou un nombre quelconque de structures de données ou de systèmes de stockage. En bref, il s’agit des données et de la gestion des données de l’application.

La vue fournit effectivement l'élément d'interface utilisateur de l'application. Les données du modèle seront rendues dans un formulaire adapté à l'interface utilisateur.

Le contrôleur reçoit les entrées de l'utilisateur et passe des appels aux objets du modèle et à la vue pour effectuer les actions appropriées.

Globalement, ces trois composants travaillent ensemble pour créer les trois composants de base de MVC.

Analogie

J'ai expliqué MVC à mon père comme ceci:

MVC (Model, View, Controller) est un modèle d'organisation du code dans une application pour améliorer la maintenabilité.

Imaginez un photographe avec son appareil photo en studio. Un client lui demande de prendre une photo d'une boîte.

La boîte est le modèle , le photographe est le contrôleur et la caméra est la vue .

Parce que la boîte ne sait pas à propos de l'appareil photo ou du photographe, elle est complètement indépendante. Cette séparation permet au photographe de se déplacer dans la boîte et de diriger la caméra sous n’importe quel angle pour obtenir le plan / la vue qu’il souhaite.

Les architectures non-MVC ont tendance à être étroitement intégrées. Si la boîte, le contrôleur et la caméra étaient un seul et même objet, il faudrait alors séparer, puis reconstruire à la fois la boîte et la caméra chaque fois que nous souhaitions obtenir une nouvelle vue. En outre, prendre la photo serait toujours comme essayer de prendre un selfie - et ce n'est pas toujours très facile.

Explication détaillée

Ce n’est qu’après avoir lu la question / réponse mailliste suivante que j’ai eu l’impression de comprendre MVC. Citation: https://mail.python.org/pipermail/python-list/2006-January/394968.html

bwaha a écrit:

L'auteur fait référence à mvctree.py dans wxPython en tant qu'exemple de conception MVC. Cependant, je suis encore trop vert et je trouve cet exemple particulier trop complexe et je ne comprends pas la séparation recommandée par l'auteur.

MVC est tout au sujet de la séparation des préoccupations.

Le modèle est responsable de la gestion des données du programme (données privées et données client). Le View / Controller est chargé de fournir au monde extérieur les moyens d'interagir avec les données client du programme.

Le modèle fournit une interface interne (API) permettant aux autres parties du programme d'interagir avec lui. Le View / Controller fournit une interface externe (GUI / CLI / formulaire Web / IPC de haut niveau / etc.) permettant à tout ce qui se trouve en dehors du programme de communiquer avec lui.

Le modèle est responsable du maintien de l'intégrité des données du programme, car si elles sont corrompues, la partie est terminée. La vue / le contrôleur est responsable du maintien de l'intégrité de l'interface utilisateur, en s'assurant que toutes les vues de texte affichent des valeurs mises à jour, en désactivant les éléments de menu qui ne s'appliquent pas au focus actuel, etc.

Le modèle ne contient pas de code de vue / contrôleur; pas de classes de widgets graphiques, pas de code pour la disposition des boîtes de dialogue ou la réception des entrées de l'utilisateur. La vue / le contrôleur ne contient aucun code de modèle; pas de code pour valider les URL ou effectuer des requêtes SQL, ni d'état d'origine non plus: toutes les données détenues par les widgets servent uniquement à des fins d'affichage et représentent uniquement les vraies données stockées dans le modèle.

Maintenant, voici le test d’une véritable conception MVC: le programme doit en principe être entièrement fonctionnel même sans vue / contrôleur attaché. OK, le monde extérieur aura du mal à interagir avec elle sous cette forme, mais tant que l'on connaît les incantations appropriées de l'API modèle, le programme conservera et manipulera les données normalement.

Pourquoi est-ce possible? Eh bien, la réponse simple est que tout cela est dû au faible couplage entre les couches Modèle et Vue / Contrôleur. Cependant, ce n'est pas l'histoire complète. La clé de tout le modèle MVC est la direction dans laquelle ces connexions vont: TOUTES les instructions vont de la vue / contrôleur au modèle. Le modèle ne dit JAMAIS à la vue / au contrôleur quoi faire.

Pourquoi? Parce que dans MVC, la vue / le contrôleur est autorisé à en savoir un peu plus sur le modèle (en particulier, l’API du modèle), mais le modèle n’est pas autorisé à connaître quoi que ce soit à propos de la vue / du contrôleur.

Pourquoi? Parce que MVC consiste à créer une séparation claire des préoccupations.

Pourquoi? Pour éviter que la complexité du programme ne devienne incontrôlable et que le développeur ne soit pas englouti. Plus le programme est volumineux, plus le nombre de composants de ce programme est important. Et plus il y a de connexions entre ces composants, plus les développeurs ont de la difficulté à maintenir / étendre / remplacer des composants individuels, ou même à suivre le fonctionnement de l'ensemble du système. Posez-vous la question suivante: quand vous regardez un diagramme de la structure du programme, préférez-vous voir un arbre ou un berceau de chat? Le modèle MVC évite ce dernier en interdisant les connexions circulaires: B peut se connecter à A, mais A ne peut pas se connecter à B. Dans ce cas, A correspond au modèle et B à la vue / contrôleur.

En passant, si vous êtes pointu, vous remarquerez un problème avec la restriction «à sens unique» qui vient d'être décrite: comment le modèle peut-il informer la vue / le contrôleur des modifications apportées aux données utilisateur du modèle lorsque le modèle n'est même pas autorisé à le faire? savez-vous que la vue / le contrôleur, ne vous faites pas oublier de lui envoyer des messages? Mais ne vous inquiétez pas: il existe une solution à cela, et c'est plutôt chouette même si cela semble un peu détourné au début. Nous y reviendrons dans un instant.

Concrètement, un objet View / Controller peut alors, via l'API du modèle, 1. indiquer au modèle de faire certaines choses (commandes d'exécution) et 2. au modèle de lui donner des choses (renvoyer des données). La couche View / Controller transmet les instructions à la couche Model et extrait les informations de la couche Model.

Et c'est là votre premier exemple de MyCoolListControl va mal, car l'API pour cette classe exige que l' information soit poussé en elle, de sorte que vous êtes de retour à avoir un couplage bidirectionnel entre les couches, il ne respecte pas les règles MVC et vous le dumping de retour dans la l'architecture du berceau du chat que vous tentiez [vraisemblablement] d'éviter en premier lieu.

Au lieu de cela, la classe MyCoolListControl doit suivre le flux, en extrayant les données dont elle a besoin à partir de la couche ci-dessous, quand elle en a besoin. Dans le cas d'un widget de liste, cela signifie généralement de demander combien de valeurs il y a, puis de demander chacun de ces éléments, car c'est à peu près la façon la plus simple et la plus lâche de le faire et donc de minimiser le couplage. Et si le widget veut, par exemple, présenter ces valeurs à l'utilisateur dans un bel ordre alphabétique, alors c'est sa responsabilité; et sa responsabilité, bien sûr.

Maintenant, un dernier casse-tête, comme je l'ai déjà indiqué: comment garder l'affichage de l'interface utilisateur synchronisé avec l'état du modèle dans un système basé sur MVC?

Voici le problème: de nombreux objets View ont un état, par exemple une case à cocher peut être cochée ou décochée, un champ de texte peut contenir du texte modifiable. Cependant, MVC exige que toutes les données utilisateur soient stockées dans la couche Modèle. Par conséquent, toutes les données conservées par d'autres couches à des fins d'affichage (l'état de la case à cocher, le texte actuel du champ de texte) doivent par conséquent être une copie subsidiaire de ces données de modèle principales. Mais si l'état du modèle change, la copie de la vue de cet état ne sera plus exacte et devra être actualisée.

Mais comment? Le modèle MVC empêche le modèle d'insérer une nouvelle copie de ces informations dans la couche de vue. Zut, cela n'autorise même pas le modèle à envoyer un message à View pour lui dire que son état a changé.

Enfin presque. D'accord, la couche modèle n'est pas autorisée à parler directement à d'autres couches, car cela nécessiterait de savoir quelque chose à propos de ces couches, ce que les règles MVC empêchent. Cependant, si un arbre tombe dans une forêt et que personne ne l'entend, cela produit-il un son?

La solution, voyez-vous, est de configurer un système de notifications, en fournissant à la couche Modèle un endroit où elle peut annoncer à personne en particulier qu’elle vient de faire quelque chose d’intéressant. Les autres couches peuvent ensuite envoyer des auditeurs avec ce système de notification pour écouter les annonces qui les intéressent. La couche Modèle n'a pas besoin de savoir qui écoute (ou même si quelqu'un écoute!); il ne fait que publier une annonce puis l'oublie. Et si quelqu'un entend cette annonce et a envie de faire quelque chose par la suite - comme demander au Modèle de nouvelles données pour qu'il puisse mettre à jour son affichage à l'écran - alors tant mieux. Le modèle répertorie uniquement les notifications qu'il envoie dans le cadre de la définition de son API. et ce que quelqu'un d'autre fait avec cette connaissance est à eux.

MVC est préservé et tout le monde est heureux. Votre infrastructure d'application peut bien fournir un système de notifications intégré, ou vous pouvez écrire le vôtre sinon (voir le "modèle d'observateur").

...

Quoi qu'il en soit, espérons que cela aide. Une fois que vous avez compris les motivations de MVC, les raisons pour lesquelles les choses sont faites ainsi commencent à prendre un sens, même si, à première vue, elles semblent plus complexes que nécessaire.

À votre santé,

a

MVC est principalement un mot à la mode.

Auparavant, elle était considérée comme un modèle, mais sa définition originale de 1979 a été simplifiée, transmise, mal interprétée, prise hors contexte. Il a été mal redéfini au point de ressembler à une religion et, bien que cela aide certainement les adeptes du transport de marchandises à la défendre, son nom ne s’associe plus à un ensemble de directives rigoureuses . En tant que tel, il ne peut plus être considéré comme un modèle.

MVC n'a jamais été conçu pour décrire des applications Web.
Ni les systèmes d'exploitation modernes, ni les langues.
(dont certains ont effectivement supprimé la définition de 1979)

C'était fait pour. Et ça n'a pas marché.

Nous traitons maintenant avec un hybride obscène web-mvc qui, avec son statut de mot à la mode terrifiant , sa définition médiocre , et ses programmeurs semi-illettrés comme cible démographique, fait une publicité vraiment mauvaise pour les modèles de logiciels en général.

MVC est donc devenu la séparation des préoccupations distillées pour les personnes qui ne veulent pas trop y penser.

• Le modèle de données est traité à sens unique,
• la vue dans un autre,
• le reste est simplement nommé "contrôleur" et laissé au choix du lecteur.

Les sites Web / applications Web dans les années 90 n’avaient pas vraiment recours à la séparation des préoccupations.

C'étaient des botches horribles de code spaghetti mélangé.
Les modifications de l'interface utilisateur, les modifications de conception et les réarrangements des données ont été incroyablement difficiles, coûteux, longs, déprimants et malheureux.

Les technologies Web telles que ASP, JSP et PHP permettent trop facilement de mélanger les préoccupations de vue avec les données et les applications. Les nouveaux venus sur le terrain émettent généralement des boules de code inextricables, comme à leur époque.

Ainsi, un nombre croissant de personnes ont commencé à répéter "utiliser MVC" en boucle infinie sur les forums d'assistance. Le nombre de personnes a augmenté au point d'inclure les gestionnaires et les spécialistes du marketing (ce terme était déjà familier pour certains, depuis l'époque de la programmation gui, dans laquelle le modèle avait un sens) et cela devenait le monstre d'un mot à la mode auquel nous devons maintenant faire face. .

En l'état actuel des choses, c'est du bon sens , pas une méthodologie .
C'est un point de départ , pas une solution .
C'est comme dire aux gens de respirer de l' air ou de faire des redressements assis , pas un traitement curatif du cancer .

La meilleure façon de le définir est de consulter les écrits originaux de Trygve Reenskaug , qui l’a inventé: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

Ce document, en particulier, est généralement considéré comme le texte de définition: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

DES MODÈLES

Les modèles représentent la connaissance. Un modèle peut être un objet unique (plutôt inintéressant), ou une structure d'objets ...

Il devrait y avoir une correspondance un à un entre le modèle et ses parties, d’une part, et le monde représenté tel que le perçoit le propriétaire du modèle, d’autre part. Les nœuds d'un modèle doivent donc représenter une partie identifiable du problème.

Les nœuds d'un modèle doivent tous se situer au même niveau de problème. Il est déroutant et considéré comme une mauvaise forme de mélanger des nœuds axés sur le problème (rendez-vous du calendrier, par exemple) avec des détails de mise en œuvre (paragraphes, par exemple).

VUES

Une vue est une représentation (visuelle) de son modèle. Cela mettrait généralement en évidence certains attributs du modèle et en supprimerait d’autres. Il agit donc comme un filtre de présentation .

Une vue est attachée à son modèle (ou partie de modèle) et obtient du modèle les données nécessaires à la présentation en posant des questions. Il peut également mettre à jour le modèle en envoyant des messages appropriés. Toutes ces questions et messages doivent être dans la terminologie du modèle, la vue devra donc connaître la sémantique des attributs du modèle qu’elle représente. (Il peut, par exemple, demander l’identifiant du modèle et attendre une instance de Text, mais ne peut pas supposer que le modèle est de classe Text.)

CONTROLEURS

Un contrôleur est le lien entre un utilisateur et le système. Il fournit à l'utilisateur des informations en organisant des vues pertinentes pour qu'elles se présentent aux endroits appropriés à l'écran. Il fournit un moyen de sortie utilisateur en présentant à l'utilisateur des menus ou d'autres moyens de donner des commandes et des données. Le contrôleur reçoit cette sortie utilisateur, la traduit en messages appropriés et les transmet à une ou plusieurs vues.

Un contrôleur ne doit jamais compléter les vues, il ne doit par exemple jamais connecter les vues de nœuds en traçant des flèches entre eux.

Inversement, une vue ne doit jamais connaître les entrées de l'utilisateur, telles que les opérations à la souris et les frappes au clavier. Il devrait toujours être possible d'écrire une méthode dans un contrôleur qui envoie des messages aux vues qui reproduisent exactement toute séquence de commandes utilisateur.

ÉDITEURS

Un contrôleur est connecté à toutes ses vues, elles sont appelées les parties du contrôleur. Certaines vues fournissent un contrôleur spécial, un éditeur , qui permet à l'utilisateur de modifier les informations présentées par la vue. De tels éditeurs peuvent être fusionnés dans le chemin entre le contrôleur et sa vue, et agiront comme une extension du contrôleur. Une fois le processus d'édition terminé, l'éditeur est supprimé du chemin et supprimé.

Notez qu'un éditeur communique avec l'utilisateur via les métaphores de la vue connectée, l'éditeur est donc étroitement associé à la vue. Un contrôleur obtiendra un éditeur en demandant la vue - il n’existe aucune autre source appropriée.

MVC est un modèle de conception utilisé pour isoler la logique métier de la présentation.

Il diffère de beaucoup d'autres modèles de conception par le fait qu'il n'est généralement pas implémenté de manière succincte, mais constitue la base d'un cadre.

Bien qu'une application mettant en œuvre un modèle de stratégie ne constitue qu'un détail, elle est très déterminante de dire qu'une application Web utilise le modèle de conception MVC .

MVC est une conception de logiciel qui sépare les composants suivants d'un système ou d'un sous-système:

1. Modèle - Données sur l'état de l'application ou de ses composants. Peut inclure des routines de modification ou d'accès.
2. Voir - Une interprétation des données (modèle). Cela se limite à une représentation visuelle, mais peut être de type audio, des informations dérivées (par exemple des statistiques transférées dans un autre objet du modèle), etc. De plus, un même modèle peut avoir plusieurs vues.
3. Contrôle: gère les entrées externes du système en invoquant des modifications sur le modèle. Le contrôle / vue peut être étroitement lié (dans le cas d'une interface utilisateur). Cependant, d'autres entrées externes (telles que les commandes réseau) peuvent être traitées, lesquelles sont complètement indépendantes de la vue.

Je dirais que MVC est un concept ou une famille de modèles similaires.

Je pense que cet article vaut la peine d'être lu. Architectures GUI par Martin Fowler

Tout d'abord, vous devez déterminer qui est le demandeur de la question et quel type de réponse il recherche. Vous répondez à cette question par une autre, telle que "Dans quel sens?"

Vous pouvez demander s’ils font référence à MVC en général, à une implémentation particulière de MVC (c’est-à-dire asp.net MVC, spring MVC, smalltalk MVC, etc.), de quoi s'agit-il techniquement, de quoi s'agit-il philosophiquement (oui, la philosophie aussi), etc.

S'il s'agit d'une question sur un test et que vous ne pouvez pas demander au demandeur de clarifier, vous devrez deviner en fonction du contexte.

Une bonne réponse simple est:

MVC est une architecture d'interface utilisateur utilisée pour séparer les problèmes de structure et de comportement afin de faciliter la maintenance du logiciel.

Vous pouvez également dire:

En séparant la vue du contrôleur du modèle, il encourage l'isolation des composants en fonction de leurs responsabilités. En théorie, et généralement en pratique, cela contribue à améliorer la maintenabilité en empêchant les différentes parties du système de se mélanger et de créer des systèmes plus complexes.

Mais, à la fin, vous serez jugé sur le fait que vous donniez la réponse attendue. La seule solution au problème est de savoir quel type de réponse ils attendent.

Voici ce que je dirais à ce sujet. J'essaierais de l'expliquer en termes d'applications mobiles, parce que c'est ce que je connais le mieux et parce que je ne pense pas l'avoir bien comprise avant de commencer à faire des applications mobiles.
Prenons Android par exemple.
Couche de présentation, à savoir. l’interface utilisateur peut (devrait, le plus souvent est) être spécifiée entièrement en xml. Par souci de simplicité, supposons qu'un fichier XML décrive un écran de l'application. Le fichier XML spécifie les contrôles, la disposition des contrôles, le positionnement, les couleurs, la taille, les étiquettes de chaîne ... tout ce qui concerne la présentation. Pourtant, il ne sait pas quand il sera appelé, quand sera-t-il placé à l'écran. Sera-ce une mise en page autonome ou une partie d'une plus grande mise en page? Il vous en avez: votre parfaite VIEW .

Maintenant, la vue doit évidemment être placée à l'écran à un moment donné, alors comment faire? Votre contrôleur , dans Android appelé activité. Comme son nom l'indique, l'activité fait de l'activité. Même si son seul objectif est d'afficher la vue définie à l'étape 1, il effectuera une action. Ainsi, l'activité va chercher une vue et l'affiche à l'écran. Comme view ne sait rien de l'activité, de même l'activité ne sait rien de la présentation. Nous (les programmeurs) pourrions réorganiser la disposition de la vue plusieurs fois, sans changer même une ligne de code dans notre activité.

Désormais, il n’est pas très utile de présenter votre belle présentation xml brillante et bien définie sans réellement faire quelque chose. Disons que nous voulons stocker les données saisies par l'utilisateur. Activity doit s'attaquer à ce processus en prenant les données de l'utilisateur pour les transmettre à une autre personne (les traiter, les stocker, les supprimer). À qui passera-t-il? Eh bien, pour un modèle . J'aime penser à un modèle pur. classe java qui ignore tout du contexte d'application. (En pratique, ce ne sera presque jamais le cas).

Disons que j'ai une personne de classe qui a trois propriétés: nom, adresse, âge. Ma mise en page définie par XML comporte 3 champs de saisie utilisateur: nom, adresse et âge. Mon activité prend les trois valeurs de l'entrée utilisateur, crée un nouvel objet Personne et appelle une méthode dessus qui sait gérer une logique spécifique à une personne. Voilà. Modèle Vue Contrôleur.

Je commence toujours par leur dire que le motif n'est pas nouveau et qu'il existe depuis de nombreuses années ... c'est à ce moment-là qu'ils me donnent un regard inquisiteur et que BAM !, ils sont accrochés:

Et puis, je parlerai assez bien des divers points comme les réponses précédentes, mais je pense qu’il est également important d’être contextuel, comme JB King l’a dit, ASP.NET MVC, etc.