Modèle-View-Contrôleur (MVC) : entrée, mise à jour, rendu

Modèle-View-Contrôleur (MVC) : entrée, mise à jour, rendu

Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.

Comment lire ce visuel

• Suivez la boucle dans l'ordre dans lequel les flèches la dessinent : de l'utilisateur au contrôleur, au modèle à visualiser et de retour à l'utilisateur.
• Les trois colonnes sont les trois actes : l'entrée arrive, les mises à jour d'état, le rendu de la sortie.
• Les voies sont la séparation des entreprises : chaque voie possède un type de travail, et aucune voie n'effectue celle d'un autre.

Saisir

« L'utilisateur interagit avec l'interface » démarre la boucle, et « le contrôleur reçoit l'entrée » est l'agent de la circulation : il lit l'action, décide de ce que cela signifie et instruit le modèle. Le commentaire du contrôleur rend la règle explicite : il ne détient aucun état lui-même, c'est pourquoi il peut gérer de nombreuses requêtes sans se souvenir de rien.

Mise à jour

« Le contrôleur met à jour le modèle » entre dans la voie du modèle, et « Le modèle contient l'état et les règles métier » est la définition du modèle : il s'agit de la source unique de vérité pour les données et les règles qui les régissent. "Le modèle informe les observateurs du changement" est la moitié de la notification : le modèle ne dit pas à la vue quoi dessiner, il annonce seulement que quelque chose a changé, et n'importe quel nombre de vues peut écouter.

Rendu

"Voir les nouveaux rendus à partir du modèle" est le seul travail de la vue : lire le modèle et l'afficher. Son commentaire souligne la discipline qui empêche MVC de s'effondrer : la vue ne modifie jamais les données, elle se contente de demander et d'afficher. "L'utilisateur voit l'interface mise à jour" ferme le cercle dans la ligne de l'utilisateur, où commence et se termine chaque interaction.

Relations et enseignements clés

• Le contrôleur gère les entrées ; le modèle possède l'État ; la vue donne : trois responsabilités, trois voies.
• Ni la vue ni le contrôleur n'écrivent de données ; tous les changements transitent par le modèle.
• Le modèle informe les observateurs plutôt que de commander la vue, de sorte qu'un modèle peut piloter plusieurs vues.
• La séparation rend chaque partie testable individuellement : la récompense originale du modèle.
• MVC est l'ancêtre de nombreux modèles modernes (MVVM, MVP, magasins de style Redux), préservant tous la même séparation.

Quand utiliser ce visuel

• Présentation du modèle à un développeur avant de lire la documentation d'un framework : le triangle est la carte implémentée par chaque framework.
• Expliquer pourquoi une base de code est difficile à modifier : l'état géré dans la vue est une violation MVC et il est visible sur le canevas.
• Comparaison de MVC avec les architectures en couches dans le visuel d'architecture propre.

Comment cela fonctionne

1. Cartographiez votre cadre sur le triangle

   Renommez les trois cases avec les éléments de votre framework actuel (un fichier de routes comme contrôleur, vos modèles ORM comme modèle, vos modèles comme vue) pour que le modèle soit concret.

2. Ajouter l'étape du routeur

   Insérez une étape de routage entre l'utilisateur et le contrôleur si votre framework en possède une, connectée au contrôleur auquel il envoie.

3. Afficher plusieurs vues

   Ajoutez une deuxième boîte de vue écoutant toutes deux le même modèle (une liste et une vue détaillée) pour démontrer la relation d'observateur sur laquelle repose le modèle.

4. Ajouter la couche de persistance

   Étendez le modèle avec une étape de base de données, en notant que le modèle en est propriétaire et que le contrôleur et la vue ne le touchent jamais directement.

Questions fréquentes

Qu’est-ce que MVC ?

MVC (Modèle-View-Contrôleur) est un modèle logiciel qui divise une application en trois parties : le contrôleur gère les entrées, le modèle possède les données et les règles métier, et la vue restitue le modèle. L'avantage de la séparation est que chaque pièce peut être développée et testée indépendamment, et que le même modèle peut être représenté par de nombreuses vues. C’est le modèle sur lequel la plupart des frameworks Web sont construits.

Pourquoi le modèle est-il au centre de MVC ?

Parce que le modèle est la seule source de vérité. Si le contrôleur et la vue pouvaient écrire des données, ils dériveraient et se disputeraient l'état. Conserver toutes les modifications dans le modèle signifie qu’il existe exactement un seul endroit où résident les règles de données, et que la vue est toujours une projection d’un modèle cohérent. Le visuel place les deux boîtes de modèles dans leur propre voie pour cette raison.

Que se passe-t-il si je mets de la logique dans la vue ?

Vous obtenez un anti-modèle parfois appelé « fat view » : du code d'affichage mélangé à des règles métier, qui ne peut être testé sans rendu, et qui s'écarte du modèle. La même critique s’applique à un contrôleur qui détient la logique métier au lieu de déléguer. La discipline de MVC est que chaque voie reste dans sa voie : les trois lignes distinctes du visuel constituent la règle rendue visible.

Quel est le lien entre MVC et les frameworks modernes ?

La plupart des frameworks modernes conservent le triangle avec de nouveaux noms : MVVM ajoute une couche de modèle de vue, MVP donne à la vue un présentateur et les bibliothèques de gestion d'état comme Redux sont essentiellement le modèle avec une règle de notification plus stricte. La boucle centrale du canevas (l'entrée change d'état, l'état pilote la sortie) est l'invariant que chacun d'entre eux conserve.

Modifier ce visuel dans QueryChart (FlowJam)

Ouvrez ce canevas MVC exact en tant que votre propre graphique, renommez les cases en votre framework et tracez votre propre chemin de requête.

Modifier ce visuel dans QueryChart (FlowJam)