Aller au contenu

Modèle-vue-contrôleur

Un article de Wikipédia, l'encyclopédie libre.
(Redirigé depuis Modèle-Vue-Contrôleur)
Page d’aide sur l’homonymie

Pour les articles homonymes, voir MVC.

Interactions entre le modèle, la vue et le contrôleur. En réalité c'est le contrôleur qui interagit entre le modèle et la vue d'une part et entre l'utilisateur et le serveur informatique d'autre part.

Modèle-vue-contrôleur ou MVC est un motif d'architecture logicielle destiné aux interfaces graphiques, lancé en 1978 et très populaire pour les applications web. Le motif est composé de trois types de modules ayant trois responsabilités différentes : les modèles, les vues et les contrôleurs.

  • Un modèle (Model) contient les données à afficher ;
  • Une vue (View) contient la présentation de l'interface graphique ;
  • Un contrôleur (Controller) contient la logique concernant les actions effectuées par l'utilisateur.

Ce motif est utilisé par de nombreux frameworks pour applications web tels que Ruby on Rails, Grails, ASP.NET MVC, Spring, Struts, Symfony, Apache Tapestry, Laravel, AdonisJS[1], Django ou AngularJS.

Histoire

[modifier | modifier le code]

Le motif MVC a été créé par Trygve Reenskaug lors de sa visite du Palo Alto Research Center (abr. PARC) en 1978[2]. Le nom original est thing model view editor pattern, puis il a été rapidement renommé model-view-controller pattern[2]. Le patron MVC a été utilisé la première fois pour créer des interfaces graphiques avec le langage de programmation Smalltalk en 1980[2].

Description

[modifier | modifier le code]

Une application conforme au motif MVC comporte trois types de modules : les modèles, les vues et les contrôleurs[3].

Modèle
Élément qui contient les données ainsi que de la logique en rapport avec les données : validation, lecture et enregistrement[4]. Il peut, dans sa forme la plus simple, contenir uniquement une simple valeur, ou une structure de données plus complexe[5]. Le modèle représente l'univers dans lequel s'inscrit l'application[3]. Par exemple pour une application de banque, le modèle représente des comptes, des clients, ainsi que les opérations telles que dépôt et retraits, et vérifie que les retraits ne dépassent pas la limite de crédit[3].
Vue
Partie visible d'une interface graphique[4]. La vue se sert du modèle, et peut être un diagramme, un formulaire, des boutons, etc[4]. Une vue contient des éléments visuels ainsi que la logique nécessaire pour afficher les données provenant du modèle[4]. Dans une application de bureau classique, la vue obtient les données nécessaires à la présentation du modèle en posant des questions. Elle peut également mettre à jour le modèle en envoyant des messages appropriés[5]. Dans une application web une vue contient des balises HTML[3].
Contrôleur
Module qui traite les actions de l'utilisateur, modifie les données du modèle et de la vue[4].

Dépendances

[modifier | modifier le code]

Le modèle est indépendant des autres modules. Il ne se sert ni de la vue ni du contrôleur, il peut cependant leur envoyer des messages[4]. Il y a deux liens entre la vue et le modèle : premièrement la vue lit les données du modèle et deuxièmement reçoit des messages provenant du modèle[4]. Dans la mesure où une vue est associée à un modèle et un modèle est indépendant, un même modèle peut être utilisé par plusieurs vues[4].

Les aspects de la gestion des entrées/sorties de l'interface utilisateur sont techniquement très différents et ont des interdépendances faibles[6]. La gestion des entrées est déléguée au contrôleur alors que la gestion des sorties est à la charge de la vue[6].

La vue est dépendante du modèle. Elle interroge celui-ci pour en afficher une représentation.

Le contrôleur dépend de la vue et du modèle : la vue comporte des éléments visuels que l'utilisateur peut actionner[4]. Le contrôleur répond aux actions effectuées sur la vue et modifie les données du modèle[4].

Dans le cas d'un view model, le modèle contient les données que le contrôleur transmet à la vue[3]. Dans le cas d'un domain model il contient toutes les données en rapport avec l'activité, ainsi que la logique des opérations de modification et de validation des données[3].

MVP et MVVM

[modifier | modifier le code]

Les motifs model-view-presenter (MVP) et model-view-view model (MVVM) sont semblables au motifs modèle-vue-contrôleur, à quelques différences près[7].

  • Dans le patron MVP, le contrôleur est remplacé par une présentation. La présentation est créée par la vue et lui est associée par une interface. Les actions utilisateur déclenchent des événements sur la vue, et ces événements sont propagés à la présentation en utilisant l'interface[7].
  • Dans le patron MVVM il y a une communication bidirectionnelle entre la vue et le modèle, les actions de l'utilisateur entraînent des modifications des données du modèle[7].

Dans les applications web

[modifier | modifier le code]
Représentation des interactions entre le modèle, la vue et le contrôleur dans le cas d'une application web.

Le motif MVC a été créé dans le but de mettre en œuvre des interfaces utilisateur[3]. Certains détails sont alignés avec le langage Smalltalk, mais les grandes lignes peuvent s'appliquer à n'importe quel environnement[3]. Le cycle action → mise à jour → affichage induit par ce patron est bien adapté aux applications web[3]. De plus le patron impose la séparation des préoccupations, et les balises HTML sont ainsi confinées aux vues, ce qui améliore la maintenabilité de l'application[3]. C'est le framework pour applications web Ruby on Rails qui a apporté un regain d'intérêt pour ce patron[3].

Ce patron est utilisé par de nombreux frameworks pour applications web tels que Ruby on Rails, Django, ASP.NET MVC, Spring, Struts ou Apache Tapestry[2].

Dans la mise en œuvre classique du patron MVC, la vue attend des modifications du modèle, puis modifie la présentation des éléments visuels correspondants[8]. Cette mise en œuvre est appliquée pour les applications de bureau avec des framework comme Swing[8]. Le protocole HTTP ne permet pas cette mise en œuvre pour les applications web. Pour ces dernières, lors d'une action de l'utilisateur, le contenu de la vue est recalculé puis envoyé au client[8].

Flux de traitement

[modifier | modifier le code]

En résumé, lorsqu'un client envoie une requête à l'application :

  • la requête envoyée depuis la vue est analysée par le contrôleur (via par exemple un handler ou callback) ;
  • le contrôleur demande au modèle approprié d'effectuer les traitements et notifie à la vue que la requête est traitée ;
  • la vue notifiée fait une requête au modèle pour se mettre à jour (par exemple affiche le résultat du traitement via le modèle).

Avantages

[modifier | modifier le code]
Cette section ne cite pas suffisamment ses sources (janvier 2017). 
Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Cela simplifie la tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le projet. En effet, la modification des traitements ne change en rien la vue. Par exemple on peut passer d'une base de données de type SQL à XML en changeant simplement les traitements d'interaction avec celle-ci, et les vues ne s'en trouvent pas affectées.

Le MVC montre ses limites dans le cadre des applications utilisant les technologies du web, bâties à partir de serveurs d'applications[réf. nécessaire]. Des couches supplémentaires sont alors introduites ainsi que les mécanismes d'inversion de contrôle et d'injection de dépendances[9].

Différence avec l'architecture trois niveaux (3-tiers)

[modifier | modifier le code]
Cette section ne cite pas suffisamment ses sources (janvier 2017). 
Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.
Article détaillé : Architecture trois tiers.

L'architecture trois niveaux (3-tier) est un modèle en couches, c'est-à-dire que chaque couche communique seulement avec ses couches adjacentes (supérieures et inférieures) et le flux de contrôle traverse le système de haut en bas. Les couches supérieures contrôlent les couches inférieures, c'est-à-dire que les couches supérieures sont toujours sources d'interaction (clients) alors que les couches inférieures ne font que répondre à des requêtes (serveurs).

Dans le modèle MVC, il est généralement admis que la vue puisse consulter directement le modèle (lecture) sans passer par le contrôleur. Par contre, elle doit nécessairement passer par le contrôleur pour effectuer une modification (écriture). Ici, le flux de contrôle est inversé par rapport au modèle en couches, le contrôleur peut alors envoyer des requêtes à toutes les vues de manière qu'elles se mettent à jour.

Dans l'architecture trois niveaux, si une vue modifie les données, toutes les vues concernées par la modification doivent être mises à jour, d'où l'utilité de l'utilisation du MVC au niveau de la couche de présentation. La couche de présentation permet donc d'établir des règles du type « mettre à jour les vues concernant X si Y ou Z sont modifiés ». Mais ces règles deviennent rapidement trop nombreuses et ingérables si les relations logiques sont trop élevées. Dans ce cas, un simple rafraîchissement des vues à intervalle régulier permet de surmonter aisément ce problème. Il s'agit d'ailleurs de la solution la plus répandue en architecture trois niveaux, l'utilisation du MVC étant moderne et encore marginale.

Exemples d’architecture MVC

[modifier | modifier le code]

En ASP.NET

[modifier | modifier le code]
Article détaillé : ASP.NET MVC.

En C++

[modifier | modifier le code]

En JavaScript

[modifier | modifier le code]
Article détaillé : JavaScript.
  • AngularJS: Un ensemble de fonctions basées sur l'extension du vocabulaire HTML.
  • Ember.js: Fournis un canvas écrit avec Handlebars, ainsi que des vues, des contrôleurs, des modèles et un « routeur ».
  • Knockout: Tente de simplifier les interfaces utilisateurs JavaScript en utilisant le modèle Model-View-View.
  • Agility.js: À pour but de permettre aux développeurs d'écrire du code navigateur maintenable et réutilisable sans la verbosité ni la complexité des autres bibliothèques logicielle MVC.
  • CanJS: Fait en sorte de trouver un équilibre entre la taille, la facilité d'utilisation, la sécurité, la vitesse et la flexibilité.
  • Spine: Un framework léger qui s'applique à avoir une documentation facile à comprendre.
  • Sammy.js: Un léger framework JavaScript développé pour fournir une structure de base au développement d'applications JavaScript.
  • rAppid.js: Permet l'encapsulation de fonctions complexes en composants pouvant facilement être utilisés comme des éléments HTML dans une application.
  • Serenade.js: Tente de suivre les idées d'un MVC classique plutôt que d'essayer de rivaliser avec les autres frameworks.

En TypeScript

[modifier | modifier le code]
Article détaillé : TypeScript.

En ECMAScript

[modifier | modifier le code]
Article détaillé : ECMAScript.

En Groovy

[modifier | modifier le code]

En Java

[modifier | modifier le code]
Article détaillé : Java (technique).

En Objective-C

[modifier | modifier le code]
Article détaillé : Objective-C.

En Perl

[modifier | modifier le code]
Article détaillé : Perl (langage).

Frameworks orientés Web en Perl :

  • Catalyst ;
  • CGI::Application : basé sur le module Perl CGI.pm ;
  • Dancer ;
  • Gantry : similaire à Django ;
  • Jifty ;
  • MasonX ;
  • MayPole : superposition de Catalyst ;
  • O2 ;
  • Plack ;
  • Solstice ;
  • Squatting ;
  • Mojolicious.

En PHP

[modifier | modifier le code]
Article détaillé : PHP.

Frameworks basés sur l'architecture MVC :

L'utilisation d'un Framework n'est pas une obligation[10].

En Python

[modifier | modifier le code]
Article détaillé : Python (langage).

En Ruby

[modifier | modifier le code]
Article détaillé : Ruby.

Voir aussi

[modifier | modifier le code]

Notes et références

[modifier | modifier le code]
  1. ↑ (en) AdonisJS core team, « AdonisJS - A fully featured web framework for Node.js », sur adonisjs.com (consulté le ).
  2. ↑ a b c et d (en) Stephen Walther, ASP.NET MVC Framework Unleashed, Sams Publishing - 2009, (ISBN 9780768689785)
  3. ↑ a b c d e f g h i j et k (en) Adam Freeman et Steven Sanderson, Pro ASP.NET MVC 3 Framework, Apress - 2011, (ISBN 9781430234043)
  4. ↑ a b c d e f g h i et j (en) Joey Lott et Danny Patterson, Advanced ActionScript with Design Patterns, Adobe Press - 2007, (ISBN 9780132701372)
  5. ↑ a et b « MODELS - VIEWS - CONTROLLERS », sur heim.ifi.uio.no, .
  6. ↑ a et b « The Model-View-Controller (MVC) Its Past and Present », sur heim.ifi.uio.no, .
  7. ↑ a b et c (en) John Ciliberti, ASP.NET MVC 4 Recipes : A Problem-Solution Approach, Berkeley, Apress, , 632 p. (ISBN 978-1-4302-4774-6, lire en ligne)
  8. ↑ a b et c (en) Colin Yates - Seth Ladd - Marten Deinum - Koen Serneels et Christophe Vanfleteren, Pro Spring MVC: With Web Flow, Apress - 2012, (ISBN 9781430241553)
  9. ↑ (en) Fabien Potencier, « What is Dependency Injection? », 26 mars 2009.
  10. ↑ http://blog.nalis.fr/index.php?post/2009/10/19/Architecture-%3A-Le-Design-Pattern-MVC-en-PHP exemple d'implémentation MVC en PHP ]
v · m
Création
Structure
Comportement
Fonctionnel
Patron d'architecture
Autres patrons
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Modèle-vue-contrôleur&oldid=220327213 ».