Modèle–vue–contrôleur

Le modèle-vue-contrôleur ( MVC ) est un modèle de conception de logiciel couramment utilisé pour développer des interfaces utilisateur qui divise la logique du programme associé en trois éléments interconnectés. Ces éléments sont :

• le modèle , les représentations internes de l'information
• la vue , l'interface qui présente les informations à l'utilisateur et les accepte
• le contrôleur , le logiciel reliant les deux.

Traditionnellement utilisé pour les interfaces utilisateur graphiques (GUI) de bureau, ce modèle est devenu populaire pour la conception d'applications Web . Les langages de programmation populaires ont des frameworks MVC qui facilitent la mise en œuvre du modèle.

L'une des idées fondamentales dans le développement précoce des interfaces utilisateur graphiques, MVC est devenue l'une des premières approches pour décrire et implémenter des constructions logicielles en fonction de leurs responsabilités .

Trygve Reenskaug a créé MVC alors qu'il travaillait sur Smalltalk -79 en tant que chercheur invité au Xerox Palo Alto Research Center (PARC) à la fin des années 1970. Il voulait un modèle qui pourrait être utilisé pour structurer n'importe quel programme où les utilisateurs interagissent avec un ensemble de données volumineux et alambiqué . Sa conception comportait initialement quatre parties : modèle , vue, objet et éditeur. Après en avoir discuté avec les autres développeurs de Smalltalk , lui et le reste du groupe ont opté pour le modèle, la vue et le contrôleur à la place.

Dans leur conception finale, un modèle représente une partie du programme de manière pure et intuitive. Une vue est une représentation visuelle d'un modèle, récupérant des données du modèle pour les afficher à l'utilisateur et transmettant des requêtes entre l'utilisateur et le modèle. Un contrôleur est une partie organisationnelle de l'interface utilisateur qui présente et coordonne plusieurs vues à l'écran, et qui reçoit les entrées de l'utilisateur et envoie les messages appropriés à ses vues sous-jacentes. Cette conception comprend également un éditeur en tant que type de contrôleur spécialisé utilisé pour modifier une vue particulière, et qui est créé via cette vue.

Smalltalk-80 prend en charge une version de MVC qui a évolué à partir de celle-ci. Il fournit des classesview abstraites et ainsi que diverses sous-classes concrètes de chacune qui représentent différents widgets génériques . Dans ce schéma, a représente une manière d'afficher des informations à l'utilisateur, et a représente une manière pour l'utilisateur d'interagir avec a . A est également couplé à un objet modèle, mais la structure de cet objet est laissée au programmeur d'application . L'environnement Smalltalk-80 comprend également un « inspecteur MVC », un outil de développement permettant de visualiser la structure d'un modèle, d'une vue et d'un contrôleur donnés côte à côte. controller Viewcontrollerviewview

En 1988, un article paru dans The Journal of Object Technology (JOT) par deux anciens employés du PARC présentait MVC comme un « paradigme et une méthodologie de programmation » généraux pour les développeurs Smalltalk-80. Cependant, leur schéma différait de celui de Reenskaug et al. et de celui présenté par les ouvrages de référence Smalltalk-80. Ils définissaient une vue comme couvrant toute préoccupation graphique, un contrôleur étant un objet plus abstrait, généralement invisible, qui reçoit les entrées de l'utilisateur et interagit avec une ou plusieurs vues et un seul modèle.

Le modèle MVC a ensuite évolué, donnant naissance à des variantes telles que le modèle-vue-contrôleur hiérarchique (HMVC), le modèle-vue-adaptateur (MVA), le modèle-vue-présentateur (MVP), le modèle-vue-vue-modèle (MVVM) et d'autres qui ont adapté MVC à différents contextes.

L'utilisation du modèle MVC dans les applications Web s'est développée après l'introduction de WebObjects de NeXT en 1996, qui était à l'origine écrit en Objective-C (qui s'inspirait largement de Smalltalk) et a contribué à renforcer les principes MVC. Plus tard, le modèle MVC est devenu populaire auprès des développeurs Java lorsque WebObjects a été porté sur Java . Les frameworks ultérieurs pour Java, tels que Spring (sorti en octobre 2002), ont perpétué le lien fort entre Java et MVC.

En 2003, Martin Fowler a publié Patterns of Enterprise Application Architecture , qui présentait MVC comme un modèle dans lequel un « contrôleur d'entrée » reçoit une requête, envoie les messages appropriés à un objet modèle, prend une réponse de l'objet modèle et transmet la réponse à la vue appropriée pour affichage. Ceci est proche de l'approche adoptée par le framework d'application Web Ruby on Rails (août 2004), qui fait que le client envoie des requêtes au serveur via une vue dans le navigateur , ces requêtes sont traitées par un contrôleur sur le serveur, et le contrôleur communique avec les objets modèles appropriés. Le framework Django (juillet 2005, pour Python ) a proposé une version similaire de « modèle de vue de modèle » (MTV) du modèle, dans laquelle une vue récupère des données à partir de modèles et les transmet à des modèles pour affichage. Rails et Django ont tous deux fait leurs débuts en mettant l'accent sur le déploiement rapide, ce qui a accru la popularité de MVC en dehors de l'environnement d'entreprise traditionnel dans lequel il a longtemps été populaire.

Le composant central du modèle. Il s'agit de la structure de données dynamique de l'application , indépendante de l'interface utilisateur. Il gère directement les données, la logique et les règles de l'application. Dans Smalltalk-80, la conception d'un type de modèle est entièrement laissée au programmeur. Avec WebObjects, Rails et Django, un type de modèle représente généralement une table dans la base de données de l'application . Le modèle est essentiel pour garder les données organisées et cohérentes. Il garantit que les données de l'application se comportent conformément aux règles et à la logique définies.

Toute représentation d'informations telle qu'un graphique , un diagramme ou un tableau. Plusieurs vues d'une même information sont possibles, comme un graphique à barres pour la gestion et une vue tabulaire pour les comptables .

Dans Smalltalk-80, une vue est simplement une représentation visuelle d'un modèle et ne gère pas les entrées utilisateur. Avec WebObjects, une vue représente un élément d'interface utilisateur complet tel qu'un menu ou un bouton et reçoit les entrées de l'utilisateur. Cependant, dans Smalltalk-80 et WebObjects, les vues sont censées être polyvalentes et composables .

Avec Rails et Django, le rôle de la vue est joué par des modèles HTML , donc dans leur schéma une vue spécifie une interface utilisateur dans le navigateur plutôt que de représenter directement un widget d'interface utilisateur. (Django choisit d'appeler ce type d'objet un « modèle » à la lumière de cela. ) Cette approche met relativement moins l'accent sur les petites vues composables ; une vue Rails typique a une relation un à un avec une action de contrôleur.

Les vues Smalltalk-80 communiquent à la fois avec un modèle et un contrôleur, alors qu'avec WebObjects, une vue communique uniquement avec un contrôleur, qui communique ensuite avec un modèle. Avec Rails et Django, une vue/un modèle est utilisé par un contrôleur/une vue lors de la préparation d'une réponse au client.

Accepte les entrées et les convertit en commandes pour le modèle ou la vue.

Un contrôleur Smalltalk-80 gère les événements d'entrée utilisateur, tels que les pressions sur les boutons ou les mouvements de la souris. À tout moment, chaque contrôleur possède une vue et un modèle associés, bien qu'un objet modèle puisse entendre de nombreux contrôleurs différents. Un seul contrôleur, le contrôleur « actif », reçoit l'entrée utilisateur à un moment donné ; un objet gestionnaire de fenêtres global est responsable de la définition du contrôleur actif actuel. Si l'entrée utilisateur entraîne une modification d'un modèle, le contrôleur signalera au modèle de changer, mais le modèle est alors responsable de dire à ses vues de se mettre à jour.

Dans WebObjects, les vues gèrent les entrées utilisateur et le contrôleur sert d'intermédiaire entre les vues et les modèles. Il peut n'y avoir qu'un seul contrôleur par application ou un seul contrôleur par fenêtre. Une grande partie de la logique spécifique à l'application se trouve dans le contrôleur.

Dans Rails, les requêtes arrivant à l'application sur serveur depuis le client sont envoyées à un « routeur », qui associe la requête à une méthode spécifique d'un contrôleur spécifique. Dans cette méthode, le contrôleur interagit avec les données de la requête et tous les objets de modèle pertinents et prépare une réponse à l'aide d'une vue. Traditionnellement, chaque vue a un contrôleur associé ; par exemple, si l'application avait une clientvue, elle aurait généralement Clientségalement un contrôleur associé. Cependant, les développeurs sont libres de créer d'autres types de contrôleurs s'ils le souhaitent.

Django appelle l'objet jouant ce rôle une « vue » au lieu d'un contrôleur. Une vue Django est une fonction qui reçoit une requête Web et renvoie une réponse Web. Elle peut utiliser des modèles pour créer la réponse.

En plus de diviser l'application en un modèle, une vue et un composant contrôleur, le modèle de conception MVC définit les interactions entre ces trois composants :

• Le modèle est responsable de la gestion des données de l'application. Il reçoit les entrées de l'utilisateur du contrôleur.
• La vue rend la présentation du modèle dans un format particulier.
• Le contrôleur répond à l'entrée utilisateur et effectue des interactions sur les objets du modèle de données. Le contrôleur reçoit l'entrée, la valide éventuellement, puis la transmet au modèle.

Comme d'autres modèles de logiciels, MVC exprime le « cœur de la solution » à un problème tout en permettant de l'adapter à chaque système. Les conceptions MVC particulières peuvent varier considérablement par rapport à la description traditionnelle ici.

Comme l'a écrit Alan Kay en 2003, la motivation initiale du MVC était de permettre la création d'une interface graphique pour n'importe quel objet. Cela a été décrit en détail dans le livre Naked Objects de Richard Pawson .

Trygve Reenskaug, créateur de MVC au PARC, a écrit que « MVC a été conçu comme une solution générale au problème des utilisateurs contrôlant un ensemble de données volumineux et complexe. »

Dans leur guide de 1991 Inside Smalltalk , les professeurs d'informatique de l'Université Carleton, Wilf LaLonde et John Pugh, décrivaient les avantages du MVC de style Smalltalk-80 comme suit :

• indépendance de la présentation et des données, par exemple vues multiples sur un même modèle simultanément,
• widgets de présentation composables, par exemple une vue utilisée comme sous-vue d'une autre,
• modes d'entrée commutables, en échangeant un contrôleur contre un autre pendant l'exécution , et
• indépendance du traitement des entrées et des sorties, via les responsabilités séparées des contrôleurs et des vues.

Bien qu'initialement développé pour l'informatique de bureau , MVC a été largement adopté comme conception pour les applications World Wide Web dans les principaux langages de programmation . Plusieurs frameworks Web ont été créés pour appliquer ce modèle. Ces frameworks logiciels varient dans leurs interprétations, principalement dans la manière dont les responsabilités MVC sont réparties entre le client et le serveur . Les premiers frameworks MVC ont adopté une approche client léger qui plaçait presque tout le modèle, la vue et la logique du contrôleur sur le serveur. Dans cette approche, le client envoie des demandes d'hyperlien ou des soumissions de formulaire au contrôleur, puis reçoit une page Web complète et mise à jour (ou un autre document) à partir de la vue ; le modèle existe entièrement sur le serveur. Les frameworks ultérieurs ont permis aux composants MVC de s'exécuter en partie sur le client, en utilisant Ajax pour synchroniser les données.