Présentation de l'architecture MVC
L'architecture d'application la plus populaire que tout programmeur connaît est MVC . MVC signifie Modèle-Vue-Contrôleur .
Il ne s'agit pas tant de l'architecture des applications que de l'architecture des composants applicatifs, mais nous reviendrons sur cette nuance plus tard. Qu'est-ce que MVC ?
MVC est un schéma permettant de séparer les données d'application et la logique de contrôle en trois composants distincts ( modèle, vue et contrôleur ) afin que chaque composant puisse être modifié indépendamment.
- Model (Modèle) fournit des données et répond aux commandes du contrôleur en modifiant son état.
- La vue est chargée d'afficher les données du modèle à l'utilisateur en réponse aux modifications du modèle.
- Le contrôleur (Controller) interprète les actions de l'utilisateur, notifiant le modèle de la nécessité de modifications.
Ce modèle a été inventé en 1978 (!) Année. Oui, les problèmes d'architecture logicielle appropriée étaient pertinents il y a 50 ans. Voici comment ce modèle est décrit par le schéma dans l'original :
Le modèle fournit des données et des méthodes pour travailler avec eux : requêtes à la base de données, vérification de l'exactitude. Le modèle est indépendant de la vue (ne sait pas comment restituer les données) et du contrôleur (n'a pas de points d'interaction avec l'utilisateur), permettant l'accès et la gestion des données.
Le modèle est construit de manière à répondre aux requêtes en changeant son état, et la notification des "observateurs" peut être intégrée. Le modèle, du fait de son indépendance par rapport à la représentation visuelle, peut avoir plusieurs représentations différentes pour un « modèle ».
La vue est chargée d'obtenir les données requises du modèle et de les envoyer à l'utilisateur. La vue ne traite pas les entrées de l'utilisateur.
Le contrôleur assure la "communication" entre l'utilisateur et le système. Contrôle et dirige les données de l'utilisateur vers le système et vice versa. Utilise un modèle et une vue pour implémenter l'action souhaitée.
Il y a une certaine difficulté avec le fait que ce modèle a un peu évolué au fil des décennies. Autrement dit, le nom est resté le même, mais le but des pièces a commencé à changer.
Architecture MVC sur le web
L'idée derrière le modèle de conception MVC est très simple : nous devons clairement séparer la responsabilité des différents comportements dans nos applications :
Modèle— traitement des données et logique d'application.
voir— fournir des données à l'utilisateur dans n'importe quel format pris en charge.
Manette- traiter les demandes des utilisateurs et appeler les ressources appropriées.
L'application est divisée en trois composants principaux, chacun étant responsable de différentes tâches. Examinons de plus près les composants d'une application client-serveur à l'aide d'un exemple.
Manette
L'utilisateur clique sur divers éléments de la page dans le navigateur, à la suite de quoi le navigateur envoie diverses requêtes HTTP : GET, POST ou autres. Le contrôleur peut inclure le navigateur et le code JS qui fonctionnent à l'intérieur de la page.
La fonction principale du contrôleur dans ce cas est d'appeler des méthodes sur les objets nécessaires, de gérer l'accès aux ressources pour effectuer des tâches spécifiées par l'utilisateur. Généralement, le contrôleur appelle le modèle approprié pour la tâche et sélectionne la vue appropriée.
Modèle
Le modèle au sens large correspond aux données et aux règles utilisées pour travailler avec les données. Ensemble, ils constituent la logique métier de l'application. La conception d'une application commence toujours par la construction de modèles des objets sur lesquels elle opère.
Disons que nous avons une boutique en ligne qui vend des livres, alors une personne est-elle seulement un utilisateur d'une application ou également un auteur d'un livre ? Ces questions importantes doivent être abordées lors de la conception du modèle.
De plus, il existe des ensembles de règles : ce qui peut être fait, ce qui ne peut pas être fait, quels ensembles de données sont acceptables et lesquels ne le sont pas. Un livre peut-il exister sans auteur ? Et l'auteur sans livres ? La date de naissance de l'utilisateur peut-elle être en l'an 300 et ainsi de suite.
Le modèle donne au contrôleur une vue des données que l'utilisateur a demandées (message, page de livre, images, etc.). Le modèle de données sera le même quelle que soit la façon dont nous voulons le présenter à l'utilisateur. Par conséquent, nous choisissons n'importe quelle vue disponible pour afficher les données.
Le modèle contient la partie la plus importante de notre logique d'application , la logique qui résout le problème auquel nous sommes confrontés (forum, boutique, banque, etc.). Le contrôleur contient principalement la logique organisationnelle de l'application elle-même (tout comme votre chef de projet).
Voir
View propose différentes manières de représenter les données reçues du modèle. Il peut s'agir d'un modèle rempli de données. Il peut y avoir plusieurs vues différentes et le contrôleur choisit celle qui convient le mieux à la situation actuelle.
Une application Web se compose généralement d'un ensemble de contrôleurs, de modèles et de vues. Le contrôleur ne peut être que sur le backend, mais il peut également y avoir une variante de plusieurs contrôleurs, lorsque sa logique est également répartie sur le frontend. Un bon exemple de cette approche est n'importe quelle application mobile.
Exemple MVC sur le web
Disons que vous devez développer une boutique en ligne qui vendra des livres. L'utilisateur peut effectuer les actions suivantes : consulter les livres, s'inscrire, acheter, ajouter des articles à la commande en cours, marquer les livres qu'il aime et les acheter.
Votre application doit avoir un modèle responsable de toute la logique métier. Vous avez également besoin d'un contrôleur qui traitera toutes les actions de l'utilisateur et les transformera en appels de méthode à partir de la logique métier. Cependant, une méthode de contrôleur peut appeler de nombreuses méthodes de modèle différentes.
Vous avez également besoin d'ensembles de vues : une liste de livres, des informations sur un livre, un panier, une liste de commandes. Chaque page d'une application Web est en fait une vue distincte qui affiche un certain aspect du modèle à l'utilisateur.
Voyons ce qui se passe si un utilisateur ouvre une liste de livres recommandés par la librairie pour afficher les titres. L'ensemble de la séquence d'actions peut être décrit sous la forme de 6 étapes :
Pas:
- L'utilisateur clique sur le lien "recommandé" et le navigateur envoie une requête à, par exemple, /books/recommendations.
- Le contrôleur vérifie la demande : l'utilisateur doit être connecté. Ou nous devrions avoir des collections de livres pour les utilisateurs non connectés. Le contrôleur appelle alors le modèle et lui demande de retourner la liste des livres recommandés à l'utilisateur N.
- Le modèle accède à la base de données, y récupère des informations sur les livres : livres actuellement populaires, livres achetés par l'utilisateur, livres achetés par ses amis, livres de sa liste de souhaits. Sur la base de ces données, le modèle construit une liste de 10 livres recommandés et les renvoie au contrôleur.
- Le contrôleur reçoit une liste de livres recommandés et la consulte. A ce stade, le contrôleur prend des décisions ! S'il y a peu de livres ou si la liste est complètement vide, il demande une liste de livres pour un utilisateur non connecté. S'il y a une promotion en cours en ce moment, le contrôleur peut ajouter des livres promotionnels à la liste.
- Le contrôleur détermine la page à montrer à l'utilisateur. Il peut s'agir d'une page d'erreur, d'une page avec une liste de livres, d'une page félicitant que l'utilisateur soit devenu un millionième visiteur.
- Le serveur donne au client la page ( view ) sélectionnée par le contrôleur. Il est rempli avec les données nécessaires (nom d'utilisateur, liste de livres) et va au client.
- Le client reçoit la page et l'affiche à l'utilisateur.
Quels sont les avantages de cette approche ?
L'avantage le plus évident que nous obtenons de l'utilisation du concept MVC est une séparation claire de la logique de présentation (interface utilisateur) et de la logique d'application (backend).
Le deuxième avantage est la division de la partie serveur en deux : un modèle intelligent ( exécuteur ) et un contrôleur ( centre de décision ).
Dans l'exemple précédent, il y avait un moment où le contrôleur pouvait recevoir une liste vide de livres recommandés du modèle et décider quoi en faire. Théoriquement, cette logique pourrait être introduite directement dans le modèle.
Premièrement, lors de la demande de livres recommandés, le modèle décide quoi faire si la liste est vide. Ensuite, je devrais ajouter le code au même endroit, que faire s'il y a une promotion en cours maintenant, puis plus d'options différentes.
Ensuite, il s'est avéré que l'administrateur du magasin voulait voir à quoi ressemblerait la page de l'utilisateur sans promotion, ou vice versa, il n'y a pas de promotion maintenant, mais il veut voir comment la future promotion sera affichée. Et il n'y a pas de méthodes pour cela. Par conséquent, il a été décidé de séparer le centre de décision (contrôleur) de la logique métier (modèle).
En plus d'isoler les vues de la logique applicative, le concept MVC réduit considérablement la complexité des grandes applications. Le code est beaucoup plus structuré, ce qui facilite la maintenance, le test et la réutilisation des solutions.
En comprenant le concept de MVC, vous, en tant que développeur, réalisez où vous devez ajouter le tri de la liste des livres :
- Au niveau de la requête de la base de données.
- Au niveau de la logique métier (modèle).
- Au niveau de la logique métier (contrôleur).
- Dans la vue - du côté client.
Et ce n'est pas une question rhétorique. En ce moment, réfléchissez à où et pourquoi vous devez ajouter le code pour trier la liste des livres.
Modèle MVC classique
L'interaction entre les composants MVC est implémentée différemment dans les applications Web et les applications mobiles. En effet, l'application Web est de courte durée, traite une demande d'utilisateur et se ferme, tandis que l'application mobile traite de nombreuses demandes sans redémarrer.
Les applications Web utilisent généralement le modèle "passif", tandis que les applications mobiles utilisent le modèle "actif". Le modèle actif, contrairement au modèle passif, vous permet de vous abonner et de recevoir des notifications de modifications. Ceci n'est pas nécessaire pour les applications Web.
Voici à quoi ressemble l'interaction des composants dans divers modèles :
Les applications mobiles (modèle actif) utilisent activement les événements et le mécanisme d'abonnement aux événements. Avec cette approche, view ( view ) s'abonne aux modifications du modèle. Ensuite, lorsqu'un événement se produit (par exemple, l'utilisateur clique sur un bouton), le contrôleur est appelé . Il donne également au modèle une commande pour modifier les données.
Si certaines données ont changé, le modèle génère un événement sur la modification de ces données. Toutes les vues qui se sont abonnées à cet événement (pour lequel il est important de modifier cette donnée particulière) reçoivent cet événement et mettent à jour les données dans leur interface.
Dans les applications Web, les choses sont organisées un peu différemment. La principale différence technique est que le client ne peut pas recevoir de messages côté serveur à l'initiative du serveur .
Par conséquent, un contrôleur dans une application Web n'envoie généralement aucun message à la vue, mais donne au client une nouvelle page, qui est techniquement une nouvelle vue ou même une nouvelle application cliente (si une page ne sait rien de l'autre) .
À l'heure actuelle, ce problème est partiellement résolu en utilisant les approches suivantes :
- Interrogation régulière du serveur pour les modifications apportées aux données importantes (une fois par minute ou plus).
- Les WebSockets permettent à un client de s'abonner aux messages du serveur.
- Notifications push Web côté serveur.
- Le protocole HTTP/2 permet au serveur d'initier l'envoi de messages au client.
GO TO FULL VERSION