Partie 7. Présentation du modèle MVC (Modèle-Vue-Contrôleur)

Ce matériel fait partie de la série "Introduction au développement d'entreprise". Articles précédents :

• sur le réseautage
• sur l'architecture logicielle
• à propos de HTTP/HTTPS
• sur les bases de Maven
• à propos des servlets (écriture d'une application web simple)
• à propos des conteneurs de servlet

Dans cet article, nous apprendrons à connaître quelque chose appelé MVC. Nous parlerons de ce qu'est MVC, aborderons son histoire, explorerons les idées et concepts de base incarnés dans MVC, examinerons étape par étape comment diviser une application en modules Modèle, Vue et Contrôleur, rédigerons un petite application Web utilisant Spring Boot et, en utilisant Spring MVC comme exemple, voyez comment les données sont envoyées du code Java aux pages HTML. Pour comprendre ce matériau, vous devez vous familiariser avec les modèles de conception, en particulier l'observateur et la façade. Et être familiarisé avec les requêtes et les réponses HTTP, comprendre les bases du HTML et savoir ce que sont les annotations Java. Prenez une tasse de café et une collation, et installez-vous confortablement. Commençons.

Histoire de MVC

Les idées derrière MVC ont été formulées par Trygve Reenskaug alors qu'il travaillait chez Xerox PARC à la fin des années 1970. À cette époque, travailler avec des ordinateurs exigeait un diplôme et une étude constante d'une documentation volumineuse. La tâche résolue par Reenskaug avec un groupe de développeurs très forts était de simplifier l'interaction d'un utilisateur ordinaire avec l'ordinateur. Il fallait créer des outils qui, d'une part, seraient extrêmement simples et compréhensibles, et d'autre part, permettraient de contrôler des ordinateurs et des applications complexes. Reenskaug a travaillé dans une équipe qui a développé un ordinateur portable "pour les enfants de tous âges" - le Dynabook, ainsi que le langage SmallTalk sous la direction d'Alan Kay. C'est alors que les concepts d'une interface conviviale ont été définis. À bien des égards, le travail effectué par Reenskaug et son équipe a influencé l'évolution de la sphère informatique. Voici un fait intéressant qui ne s'applique pas directement à MVC, mais qui illustre l'importance de ces développements. Alan Kaya dit, "Quand je suis arrivé chez Apple, c'était en 1984, le Mac était déjà sorti et Newsweek m'a contacté et m'a demandé ce que je pensais du Mac. J'ai dit : 'Eh bien, le Mac est le premier ordinateur personnel assez bon pour être critiqué.' Ainsi, après avoir annoncé l'iPhone en 2007, il me l'a présenté et me l'a tendu. Il a dit : « Alan, est-ce assez bon pour être critiqué ? Et j'ai dit, 'Steve, fais-en cette taille aussi grande qu'une tablette et tu domineras le monde.'" Après 3 ans, le 27 janvier 2010, Apple a présenté l'iPad avec une diagonale de 9,7 pouces. En d'autres termes, Steve Jobs a suivi presque exactement les conseils d'Alan Kay. Le projet de Reenskaug a duré 10 ans. Mais la première publication sur MVC est apparue après encore 10 ans. Martin Fowler, auteur de plusieurs livres et articles sur l'architecture logicielle, mentionne qu'il a étudié MVC en utilisant une version de travail de Smalltalk. Parce qu'il n'y avait pas d'informations sur MVC de la source d'origine pendant longtemps, et pour plusieurs autres raisons, un grand nombre d'interprétations différentes de ce concept sont apparues. En conséquence, beaucoup considèrent MVC comme un modèle de conception. Plus rarement, MVC est appelé un modèle composite ou une combinaison de plusieurs modèles qui fonctionnent ensemble pour créer des applications complexes. Mais, comme mentionné précédemment, MVC est en fait principalement un ensemble d'idées/principes/approches architecturales qui peuvent être mis en œuvre de différentes manières en utilisant différents modèles... Ensuite, nous examinerons les principales idées intégrées dans le concept MVC. et pour plusieurs autres raisons, un grand nombre d'interprétations différentes de ce concept sont apparues. En conséquence, beaucoup considèrent MVC comme un modèle de conception. Plus rarement, MVC est appelé un modèle composite ou une combinaison de plusieurs modèles qui fonctionnent ensemble pour créer des applications complexes. Mais, comme mentionné précédemment, MVC est en fait principalement un ensemble d'idées/principes/approches architecturales qui peuvent être mis en œuvre de différentes manières en utilisant différents modèles... Ensuite, nous examinerons les principales idées intégrées dans le concept MVC. et pour plusieurs autres raisons, un grand nombre d'interprétations différentes de ce concept sont apparues. En conséquence, beaucoup considèrent MVC comme un modèle de conception. Plus rarement, MVC est appelé un modèle composite ou une combinaison de plusieurs modèles qui fonctionnent ensemble pour créer des applications complexes. Mais, comme mentionné précédemment, MVC est en fait principalement un ensemble d'idées/principes/approches architecturales qui peuvent être mis en œuvre de différentes manières en utilisant différents modèles... Ensuite, nous examinerons les principales idées intégrées dans le concept MVC.

MVC : idées et principes de base

• VC est un ensemble d'idées et de principes architecturaux pour la construction de systèmes d'information complexes avec une interface utilisateur
• MVC est une abréviation qui signifie : Modèle-Vue-Contrôleur

Avis de non-responsabilité : MVC n'est pas un modèle de conception. MVC est un ensemble d'idées et de principes architecturaux pour la construction de systèmes complexes avec une interface utilisateur. Mais pour plus de commodité, afin de ne pas répéter "un ensemble d'idées architecturales...", nous nous référerons au modèle MVC. Commençons par le simple. Que se cache-t-il derrière les mots Model-View-Controller ? Lorsque vous utilisez le modèle MVC pour développer des systèmes avec une interface utilisateur, vous devez diviser le système en trois composants. Ils peuvent également être appelés modules ou composants. Appelez-les comme vous voulez, mais divisez le système en trois éléments. Chaque composant a son propre objectif. Modèle. Le premier composant/module est appelé le modèle. Il contient toute la logique métier de l'application. Voir.La deuxième partie du système est la vue. Ce module est responsable de l'affichage des données à l'utilisateur. Tout ce que l'utilisateur voit est généré par la vue. Manette.Le troisième maillon de cette chaîne est le contrôleur. Il contient le code responsable de la gestion des actions de l'utilisateur (toutes les actions de l'utilisateur sont gérées dans le contrôleur). Le modèle est la partie la plus indépendante du système. Tellement indépendant qu'il ne doit rien savoir des modules view et controller. Le modèle est si indépendant que ses développeurs ne savent pratiquement rien de la vue et du contrôleur. L'objectif principal de la vue est de fournir des informations à partir du modèle dans un format que l'utilisateur peut utiliser. La principale limitation de la vue est qu'elle ne doit en aucun cas modifier le modèle. L'objectif principal du contrôleur est de gérer les actions de l'utilisateur. C'est par l'intermédiaire du contrôleur que l'utilisateur apporte des modifications au modèle. Ou plus précisément, aux données stockées dans le modèle. Voici le diagramme que vous avez vu précédemment dans la leçon : De tout cela, nous pouvons tirer une conclusion logique. Un système complexe doit être divisé en modules. Décrivons brièvement les étapes pour réaliser cette séparation.

Étape 1. Séparez la logique métier de l'application de l'interface utilisateur

L'idée principale de MVC est que toute application dotée d'une interface utilisateur peut être divisée en 2 modules : un module responsable de l'implémentation de la logique métier et l'interface utilisateur. Le premier module implémentera les fonctionnalités principales de l'application. Ce module est le cœur du système, où le modèle de domaine de l'application est implémenté. Dans le paradigme MVC, ce module est la lettre M, c'est-à-dire le modèle. Le deuxième module implémente l'ensemble de l'interface utilisateur, y compris la logique pour afficher les données à l'utilisateur et gérer l'interaction de l'utilisateur avec l'application. L'objectif principal de cette séparation est de garantir que le cœur du système (le "modèle" dans la terminologie MVC) peut être développé et testé de manière indépendante. Après avoir fait cette séparation, l'architecture de l'application ressemble à ceci :

Étape 2 Utilisez le modèle d'observateur pour rendre le modèle encore plus indépendant et pour synchroniser les interfaces utilisateur

Ici, nous avons 2 objectifs :

1. Atteindre une indépendance encore plus grande pour le modèle
2. Synchroniser les interfaces utilisateur

L'exemple suivant vous aidera à comprendre ce que nous entendons par synchronisation des interfaces utilisateur. Supposons que nous achetions un billet de cinéma en ligne et que nous voyions le nombre de places disponibles dans la salle. En même temps, quelqu'un d'autre peut acheter un billet de cinéma. Si cette autre personne achète un billet avant nous, nous aimerions voir une diminution du nombre de places disponibles pour la séance que nous envisageons. Réfléchissons maintenant à la façon dont cela peut être implémenté dans un programme. Supposons que nous ayons le cœur de notre système (notre modèle) et son interface (la page Web pour acheter des billets). Deux utilisateurs essaient de choisir simultanément une place dans le théâtre. Le premier utilisateur achète un billet. La page Web doit montrer au deuxième utilisateur que cela s'est produit. Comment est-ce censé se passer ? Si nous mettons à jour l'interface depuis le noyau, alors le noyau (notre modèle) dépendra de l'interface. Au fur et à mesure que nous développons et testons le modèle, nous devrons garder à l'esprit les différentes manières de mettre à jour l'interface. Pour ce faire, nous devons implémenter le modèle d'observateur. Ce modèle permet au modèle d'envoyer des notifications de modification à tous les écouteurs. En tant qu'écouteur d'événement (ou observateur), l'interface utilisateur reçoit des notifications et est mise à jour. D'une part, le modèle d'observateur permet au modèle d'informer l'interface (vue et contrôleur) que des changements ont eu lieu sans en savoir quoi que ce soit, restant ainsi indépendant. D'autre part, il permet de synchroniser les interfaces utilisateurs. nous devons implémenter le modèle d'observateur. Ce modèle permet au modèle d'envoyer des notifications de modification à tous les écouteurs. En tant qu'écouteur d'événement (ou observateur), l'interface utilisateur reçoit des notifications et est mise à jour. D'une part, le modèle d'observateur permet au modèle d'informer l'interface (vue et contrôleur) que des changements ont eu lieu sans en savoir quoi que ce soit, restant ainsi indépendant. D'autre part, il permet de synchroniser les interfaces utilisateurs. nous devons implémenter le modèle d'observateur. Ce modèle permet au modèle d'envoyer des notifications de modification à tous les écouteurs. En tant qu'écouteur d'événement (ou observateur), l'interface utilisateur reçoit des notifications et est mise à jour. D'une part, le modèle d'observateur permet au modèle d'informer l'interface (vue et contrôleur) que des changements ont eu lieu sans en savoir quoi que ce soit, restant ainsi indépendant. D'autre part, il permet de synchroniser les interfaces utilisateurs.

Étape 3 Séparez l'interface en vue et contrôleur

Nous continuons à diviser l'application en modules, mais maintenant à un niveau inférieur dans la hiérarchie. À cette étape, l'interface utilisateur (que nous avons séparée en un module distinct à l'étape 1) est divisée en une vue et un contrôleur. Tracer une ligne stricte entre la vue et le contrôleur est difficile. Si nous disons que la vue est ce que l'utilisateur voit et que le contrôleur est le mécanisme qui permet à l'utilisateur d'interagir avec le système, vous pourriez souligner une contradiction. Les éléments de contrôle, tels que les boutons sur une page Web ou un clavier virtuel sur l'écran d'un téléphone, font essentiellement partie du contrôleur. Mais ils sont aussi visibles pour l'utilisateur que n'importe quelle partie de la vue. Ce dont nous parlons vraiment ici, c'est de la séparation fonctionnelle. La tâche principale de l'interface utilisateur est de faciliter l'interaction de l'utilisateur avec le système.

• sortie et affichage pratique des informations système à l'utilisateur
• entrer les données et les commandes de l'utilisateur (les communiquer au système)

Ces fonctions déterminent comment l'interface utilisateur doit être divisée en modules. Au final, l'architecture du système ressemble à ceci : Et c'est ainsi que nous arrivons à une application composée de trois modules appelés le modèle, la vue et le contrôleur. Résumons :

1. Selon les principes du paradigme MVC, un système doit être divisé en modules.
2. Le module le plus important et le plus indépendant devrait être le modèle.
3. Le modèle est le cœur du système. Il devrait être possible de le développer et de le tester indépendamment de l'interface utilisateur.
4. Pour y parvenir, dans la première étape de la division, nous devons diviser le système en un modèle et une interface utilisateur.
5. Ensuite, à l'aide du modèle d'observateur, nous renforçons l'indépendance du modèle et synchronisons les interfaces utilisateur.
6. La troisième étape consiste à diviser l'interface utilisateur en un contrôleur et une vue.
7. Tout ce qui est nécessaire pour recevoir les données utilisateur dans le système se trouve dans le contrôleur.
8. Tout ce qui est nécessaire pour fournir des informations à l'utilisateur se trouve dans la vue.

Encore une chose importante à discuter avant de pouvoir boire votre chocolat chaud.

Un peu sur la façon dont la vue et le contrôleur interagissent avec le modèle

En saisissant des informations via le contrôleur, l'utilisateur modifie le modèle. Ou du moins, l'utilisateur modifie les données du modèle. Lorsque l'utilisateur reçoit des informations via des éléments d'interface (via la vue), l'utilisateur reçoit des informations sur le modèle. Comment cela peut-il arriver? Par quels moyens la vue et le contrôleur interagissent-ils avec le modèle ? Après tout, les classes de la vue ne peuvent pas appeler directement les méthodes des classes du modèle pour lire/écrire des données. Sinon, on ne pourrait pas dire que le modèle est indépendant. Le modèle est un ensemble de classes étroitement liées auxquelles ni la vue ni le contrôleur ne doivent avoir accès. Pour connecter le modèle à la vue et au contrôleur, nous devons implémenter le modèle de conception de façade. La façade du modèle est la couche entre le modèle et l'interface utilisateur, par lequel la vue reçoit des données formatées de manière pratique, et le contrôleur modifie les données en appelant les méthodes nécessaires sur la façade. Au final, tout ressemble à ça :

MVC : Qu'est-ce qu'on y gagne ?

L'objectif principal du paradigme MVC est de séparer l'implémentation de la logique métier (le modèle) de sa visualisation (la vue). Cette séparation augmente les possibilités de réutilisation du code. Les avantages de MVC sont plus évidents lorsque nous devons présenter les mêmes données dans différents formats. Par exemple, sous forme de tableau, de graphique ou de graphique (utilisant différentes vues). Dans le même temps, sans affecter la façon dont les vues sont mises en œuvre, nous pouvons modifier la façon dont nous répondons aux actions des utilisateurs (clics sur les boutons, saisie de données). Si vous suivez les principes de MVC, vous pouvez simplifier le développement de logiciels, augmenter la lisibilité du code et améliorer l'extensibilité et la maintenabilité. Dans le dernier article de la série "Introduction au développement d'entreprise", nous examinerons une implémentation MVC construite à l'aide de Spring MVC. Partie 8. Écrivons une petite application en utilisant Spring Boot