Dans ce document, nous vous présenterons quelque chose comme MVC. Parlons de ce qu'est MVC, abordons l'histoire de sa création, comprenons les principales idées et concepts inhérents à MVC, réfléchissons étape par étape à la façon de diviser une application en modules Modèle, Vue, Contrôleur, et écrivons également une petite application Web dans Spring-Boot et en utilisant Spring-MVC comme exemple, voyons comment les données sont transférées du code Java vers les pages HTML. Pour comprendre ce matériel, vous devez être familier avec les modèles de conception, en particulier Observer et Facade. Familiarisez-vous avec les requêtes et les réponses HTTP, comprenez les bases du HTML, sachez ce que sont les annotations en Java. Asseyez-vous, préparez le thé, préparez le dessert, la salade, le plat principal et l'entrée. Nous commençons.
Histoire de MVC
Les idées de MVC ont été formulées par Trygve Reenskaug alors qu'il travaillait chez Xerox PARC à la fin des années 70. À cette époque, il était impossible de travailler avec un ordinateur sans un diplôme universitaire et une étude constante d’une documentation volumineuse. Le problème que Reenskaug a résolu avec un groupe de développeurs très compétents était de simplifier l'interaction de l'utilisateur moyen avec un ordinateur. Il fallait créer des outils qui, d'une part, seraient extrêmement simples et compréhensibles, et d'autre part, permettraient de gérer un ordinateur et des applications complexes. Reenskaug a travaillé dans l'équipe qui a développé l'ordinateur portable « pour les enfants de tous âges » - Dynabook, ainsi que le langage SmallTalk sous la direction d'Alan Kay. C’est à ce moment-là que les concepts d’une interface conviviale ont été posés. Le travail de Reenskaug avec son équipe a grandement influencé le développement du domaine informatique. Présentons un fait intéressant qui ne concerne pas directement MVC, mais illustre l'importance de ces développements. En 2007, après la présentation de l'iPhone d'Apple, Alan Kay déclarait : « Quand le Macintosh est sorti, Newsweek m'a demandé ce que j'en pensais. J'ai dit : c'est le premier ordinateur personnel digne de critique. Après la présentation, Steve Jobs est venu et a demandé : l'iPhone mérite-t-il la critique ? Et j’ai dit, faites-en cinq pouces sur huit et vous conquérirez le monde. Trois ans plus tard, le 27 janvier 2010, Apple présentait l'iPad de 9,7 pouces. Autrement dit, Steve Jobs a suivi presque littéralement les conseils d'Alan Kay. Le projet sur lequel Rennskaug a travaillé a duré 10 ans. Et la première publication sur MVC de ses créateurs a été publiée 10 ans plus tard. Martin Fowler, auteur de plusieurs livres et articles sur l'architecture logicielle, mentionne qu'il a appris MVC à partir d'une version fonctionnelle de SmallTalk. Comme il n'y avait aucune information sur MVC provenant de la source principale pendant longtemps, ainsi que pour un certain nombre d'autres raisons, un grand nombre d'interprétations différentes de ce concept sont apparues. En conséquence, de nombreuses personnes considèrent MVC comme un schéma ou un modèle de conception. Plus rarement, MVC est appelé modèle composite ou combinaison de plusieurs modèles qui fonctionnent ensemble pour implémenter des applications complexes. Mais en fait, comme indiqué précédemment, MVC est avant tout un ensemble d'idées/principes/approches architecturales qui peuvent être mises en œuvre de différentes manières en utilisant divers modèles... Ensuite, nous essaierons d'examiner les idées principales intégrées dans le concept MVC.
Qu'est-ce que 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 un acronyme qui signifie Model-View-Controller.
Avertissement : MVC n'est pas un modèle de conception. MVC est précisément un ensemble d'idées et de principes architecturaux pour construire des systèmes complexes avec une interface utilisateur. Mais par commodité, afin de ne pas répéter à chaque fois : « Un ensemble d'idées architecturales... », nous appellerons MVC un modèle. Commençons par quelque chose de simple. Qu'est-ce qui se cache derrière les mots Model-View-Controller ? Lors du développement de systèmes avec une interface utilisateur, en suivant le modèle MVC, vous devez diviser le système en trois composants. Ceux-ci, à leur tour, peuvent être appelés modules ou composants. Dites ce que vous voulez, mais divisez par trois. Chaque composant aura son propre objectif. Modèle. Le premier composant/module est ce qu'on appelle 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 stocke le code responsable du traitement des actions de l'utilisateur (toute action de l'utilisateur dans le système est traitée dans le contrôleur). Le modèle est la partie la plus indépendante du système. Tellement indépendant qu'il ne devrait rien connaître 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 du modèle dans un format convivial. 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 traiter les actions des utilisateurs. C'est via le Contrôleur que l'utilisateur apporte des modifications au modèle. Plus précisément, dans les données stockées dans le modèle. Reprenons le schéma qui vous a déjà été montré lors du cours : De tout cela nous pouvons tirer une conclusion tout à fait logique. Un système complexe doit être divisé en modules. Décrivons brièvement les étapes à suivre pour parvenir à une telle séparation.
Étape 1 : Séparez la logique métier de l'application de l'interface utilisateur
L'idée clé de MVC est que toute application dotée d'une interface utilisateur peut, en première approximation, être divisée en 2 modules : un module chargé d'implémenter la logique métier de l'application, et une interface utilisateur. Le premier module implémentera les principales fonctionnalités de l'application. Ce module sera le cœur du système dans lequel le modèle de domaine d'application est implémenté. Dans le concept MVC, ce module sera notre lettre M, c'est à dire modèle. Le deuxième module mettra en œuvre l'intégralité de l'interface utilisateur, y compris l'affichage des données à l'utilisateur et la logique d'interaction de l'utilisateur avec l'application. L’objectif principal de cette séparation est de garantir que le cœur du système (Modèle dans la terminologie MVC) puisse être développé et testé de manière indépendante. L'architecture de l'application après une telle division ressemblera à ceci :
Étape 2. En utilisant le modèle Observer, obtenez une indépendance encore plus grande du modèle, ainsi qu'une synchronisation des interfaces utilisateur
Ici, nous poursuivons 2 objectifs :
Obtenez une indépendance encore plus grande du modèle.
Synchronisez les interfaces utilisateur.
L'exemple suivant vous aidera à comprendre ce que l'on entend par synchronisation des interfaces utilisateur. Disons que nous achetons un billet de cinéma en ligne et voyons le nombre de places disponibles dans la salle. Quelqu'un d'autre peut acheter un billet de cinéma en même temps que nous. Si cette personne achète un billet avant nous, nous aimerions voir que le nombre de places disponibles pour notre séance diminue. Voyons maintenant comment cela peut être implémenté dans le programme. Supposons que nous ayons un cœur de système (notre modèle) et une interface (la page Web sur laquelle nous effectuons un achat). Sur le site, 2 utilisateurs sélectionnent simultanément un siège. Le premier utilisateur a acheté un billet. Le deuxième utilisateur doit afficher ces informations sur la page. Comment cela devrait-il se produire ? Si nous mettons à jour l'interface depuis le noyau système, notre noyau, notre modèle, dépendra de l'interface. Lors du développement et du test d'un modèle, vous devrez garder à l'esprit différentes manières de mettre à jour l'interface. Pour y parvenir, vous devez implémenter le modèle Observer. Avec son aide, le modèle envoie des notifications sur les modifications à tous les abonnés. L'interface, en tant qu'abonné, recevra une notification et une mise à jour. Le modèle Observer permet au modèle, d'une part, d'informer l'interface (vue et contrôleur) que des changements se sont produits dans celle-ci, et d'autre part, de ne rien « savoir » à leur sujet, et ainsi de rester indépendant. En revanche, cela permettra de synchroniser les interfaces utilisateurs.
Étape 3. Diviser l'interface en vue et contrôleur
Nous continuons à diviser l'application en modules, mais à un niveau inférieur de la hiérarchie. Dans cette étape, l'interface utilisateur (qui a été séparée en un module distinct à l'étape 1) est divisée en une vue et un contrôleur. Il est difficile de tracer une ligne stricte entre une vue et un contrôleur. Si nous disons que la vue est ce que l'utilisateur voit et que le contrôleur est le mécanisme par lequel l'utilisateur peut interagir avec le système, il y a une certaine contradiction. Les commandes, telles que les boutons d'une page Web ou un clavier virtuel sur l'écran d'un téléphone, font essentiellement partie du contrôleur. Mais ils sont tout aussi visibles pour l’utilisateur que n’importe quelle partie de la vue. On parle ici davantage de division fonctionnelle. La tâche principale de l'interface utilisateur est d'assurer l'interaction de l'utilisateur avec le système. Cela signifie que l'interface n'a que 2 fonctions :
afficher et afficher facilement des informations sur le système à l'utilisateur ;
saisir les données utilisateur et les commandes dans le système (les transmettre au système) ;
Ces fonctions déterminent comment l'interface doit être divisée en modules. En conséquence, l'architecture du système ressemble à ceci : Nous avons donc une application de trois modules appelés Modèle, Vue et Contrôleur. Résumer:
Suivant les principes de MVC, le système doit être divisé en modules.
Le module le plus important et indépendant devrait être le modèle.
Le modèle est le cœur du système. Vous devez pouvoir le développer et le tester indépendamment de l’interface.
Pour ce faire, lors de la première étape de ségrégation du système, vous devez le diviser en un modèle et une interface.
Ensuite, en utilisant le modèle Observer, nous renforçons le modèle dans son indépendance et obtenons la synchronisation des interfaces utilisateur.
La troisième étape consiste à diviser l'interface en un contrôleur et une vue.
Tout ce qui est nécessaire pour saisir les informations de l'utilisateur dans le système se trouve dans le contrôleur.
Tout ce qui transmet les informations du système à l'utilisateur est visible.
Il reste encore une chose importante à discuter et vous pouvez boire du cacao.
Un peu sur la relation entre la vue, le contrôleur et le modèle
Lorsque l'utilisateur saisit des informations via le contrôleur, il apporte ainsi des modifications au modèle. Au moins, l'utilisateur apporte des modifications aux 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 les données du modèle. Comment cela peut-il arriver? Comment la vue et le contrôleur interagissent-ils avec le modèle ? Après tout, il ne se peut pas que les classes View utilisent directement les méthodes des classes Model pour lire/écrire des données, sinon il ne peut être question d'une quelconque indépendance du Model. Le modèle représente un ensemble de classes étroitement interconnectées auxquelles, dans le bon sens, ni la vue ni le contrôleur ne devraient avoir accès. Pour connecter le Modèle à la Vue et au Contrôleur, il est nécessaire d'implémenter le design pattern Facade. La façade du modèle sera la couche même entre le modèle et l'interface, à travers laquelle la vue reçoit les données dans un format pratique, et le contrôleur modifie les données en appelant les méthodes de façade nécessaires. Schématiquement, au final, tout ressemblera à ceci :
MVC : quel est l’avantage ?
L'objectif principal du respect des principes MVC est de séparer l'implémentation de la logique métier (modèle) de l'application de sa visualisation (vue). Cette séparation augmentera la réutilisation du code. Les avantages de l'utilisation de MVC sont plus évidents dans les cas où l'utilisateur doit fournir les mêmes données sous différentes formes. Par exemple, sous forme de tableau, de graphique ou de diagramme (en utilisant différents types). Dans le même temps, sans affecter la mise en œuvre des vues, vous pouvez modifier les réactions aux actions de l'utilisateur (clic sur un bouton, saisie de données). Si vous suivez les principes de MVC, vous pouvez simplifier l'écriture de programmes, augmenter la lisibilité du code et faciliter l'extension et la maintenance du système à l'avenir. Dans le dernier document de la série « Introduction au développement d'entreprise », nous examinerons la mise en œuvre de MVC en utilisant Spring-MVC comme exemple. Partie 8. Écrire une petite application avec Spring-Boot
De tout cela nous pouvons tirer une conclusion tout à fait logique. Un système complexe doit être divisé en modules. Décrivons brièvement les étapes à suivre pour parvenir à une telle séparation.
Nous avons donc une application de trois modules appelés Modèle, Vue et Contrôleur. Résumer:
GO TO FULL VERSION