Le MVC - Model View Controller

Introduction au MVC

Pourquoi tant de vague sur le MVC ? Qu'est-ce que c'est, et à quoi sert-il ? Aujourd'hui, on ne peut parler de framework sans citer le MVC. La question est surtout de savoir ce qu'il apporte de plus par rapport à vos habitudes de développement.

Design pattern ou technique de développement évoluée, la frontière est très mince, et les avis sont partagés. Cependant, les développeurs les plus expérimentés s'accordent à dire que le MVC est une bonne pratique. Et comme toute bonne pratique, elle n'échappe pas aux concepteurs qui en ont fait une règle, puis un modèle pour arriver finalement au patron de conception (design pattern).

A la base une technique de développement, le MVC est modélisé et traduit en différents langages de programmation (Java, PHP, #C...). Le MVC évolue et améliore par la même occasion le cadre de travail des développeurs. Des frameworks sont nés, apportant chacun leurs avantages et des inconvénients. Des idées engendrant d'autres idées ont permis le perfectionnement de cette technique.

Nécessité de passer au MVC, ou phénomène de mode ? Mais que cache réellement le MVC derrière cet acronyme ? Et comment fonctionne-t-il ?

Définition : MVC

Le MVC, acronyme de Model View Controller (Modèle Vue Contrôleur), est une technique de développement avancée devenue un design pattern, qui découpe l'application en 3 couches principales, nommées Modèle, Vue et Contrôleur. La distinction de ces couches :

  1. facilite l'organisation des sources du projet ;
  2. permet à chaque corps de métier de travailler en parallèle sur les sources qui leur sont dédiées ;
  3. réduit l'impact des modifications pour minimiser les risques d'erreur et les régressions.

L'architecture MVC

Architecture MVC, Model-View-Controller

L'objectif du MVC est de bien séparer les données, les traitements et la présentation de ces données. La règle est « diviser pour mieux régner ». Chaque couche est spécialisée, donc est dédiée aux tâches qu'elles savent faire le mieux. Ainsi,

Le patron de conception Modèle-Vue-Contrôleur sépare les problématiques liés aux composants techniques et métiers. Les composants techniques peuvent être réutilisés sur différents projets, alors que seuls les composants métiers changent. Il devient alors plus facile d'industrialiser la partie technique. C'est ainsi que les frameworks ont été créés sur la base du design pattern MVC :

  1. le Modèle traite la demande de l'utilisateur. Pour cela, il a aussi accès aux données en lecture et en écriture à la base de données ;
  2. la Vue formate les résultats du traitement retournés par le modèle pour les présenter à l'utilisateur ;
  3. le Contrôleur, quant à lui, contrôle les données de la requête avant de les passer au Modèle, gère les erreurs, communique les résultats du modèle à la vue, puis renvoie le travail de la Vue à l'utilisateur.

Grâce à ce type d'architecture, le développeur sait où intervenir et comment le faire, tout en minimisant les erreurs et les impacts sur les autres composants techniques et métiers.

Le Contrôleur - Controller

Contrôleur - Controller

Le Contrôleur est le point d'entrée de la demande de l'utilisateur. Cette demande est identifiée par une requête HTTP ou une URL, avec ou sans paramètre envoyé en méthode GET ou POST. Il existe d'autres méthodes telles que PUT, DELETE... mais qui ne sont pas encore reconnues par certains navigateurs. C'est la raison pour laquelle les méthodes GET et POST sont les plus pratiquées par les frameworks.

Le Contrôleur est la couche centrale entre le Modèle et la Vue. Son rôle consiste à coordonner les tâches à exécuter, et à gérer les erreurs. Ces dernières peuvent apparaître lors d'un contrôle de paramètres ou de l'exécution d'un traitement par le Modèle. Le Contrôleur est en fait responsable du bon déroulement de la requête de l'utilisateur, de sa réception au renvoi de la réponse à l'utilisateur.

Comme le nom « Contrôleur » l'indique, sa tâche principale est de contrôler, comprenant la gestion et la synchronisation des événements. Cela consiste à :

  1. réceptionner la requête de l'utilisateur ;
  2. effectuer un contrôle préliminaire des paramètres de la requête avant de les utiliser dans un traitement ;
  3. définir l'action à entreprendre selon la méthode appelé : GET , POST, PUT, etc. ;
  4. exécuter le traitement indiqué par la méthode ;
  5. récupérer le résultat du traitement ;
  6. gérer les erreurs si elles existent ;
  7. communiquer le résultat du traitement à la Vue afin qu'elle le formate ;
  8. récupérer les données formatées par la Vue ;
  9. renvoyer ces données à l'utilisateur.

Il faut bien comprendre que le Contrôleur ignore tout de la partie métier, et ne doit contenir aucun code métier. Il appelle les composants métiers appartement à la couche Modèle pour effectuer le traitement demandé, puis récupère le résultat ou une erreur, et enfin l'envoie à la Vue. C'est tout ce que le Contrôleur doit faire.

Le Modèle - Model

Les actions du modèle - Model

Le modèle correspond à la logique métier et utilise des composants dits métiers. Le Modèle désigne le traitement à exécuter demandé par l'utilisateur. Il est appelé par le Contrôleur après que les paramètres de la requête aient été une première fois vérifiés. Ces derniers sont des données d'entrée nécessaires à la bonne exécution du processus métier.

Afin de rendre les composants métiers plus sécurisés et stables, il est souhaitable d'insérer un traitement de contrôle plus approfondi sur les paramètres d'entrée. Bien que cela soit une action qui peut paraître redondante par rapport à celle déjà effectuée par le Contrôleur, cela n'est pas le cas. En effet, le Contrôleur ne vérifie les données qu'en surface, à savoir les données obligatoires, leur type et leur format. Tandis que le Modèle se doit être plus exigeant. Chaque composant métier doit inclure le même contrôle que celui du Contrôleur, mais en plus il doit s'assurer de la validité des données par rapport à la règle de gestion attendue.

Des écritures en base de données et des extractions de données sont fréquentes. Ces actions sont considérées comme technique car détachées du fonctionnel métier, et sont par conséquent industrialisable. Ainsi, le modèle pourra se diviser en une autre couche dédiée aux accès à la base de données, en lecture et en écriture.

Lorsque le traitement est terminé, le résultat est retourné au Contrôleur afin que ce dernier puisse le communiquer à la Vue.

Voici un exemple d'actions que peut effectuer le Modèle :

  1. contrôler les paramètres d'entrée : les données requises, le format des données ;
  2. mettre fin au processus du modèle si un paramètre n'est pas valide. Générer une exception ou retourner un code d'erreur ;
  3. vérifier la cohérences des données par rapport à la règle de gestion, et terminer le traitement en cas d'erreur ;
  4. débuter la transaction en vue d'une série d'écritures/lectures en base de données ;
  5. traiter la requête de l'utilisateur avec lecture et/ou écriture en base de données selon les besoins fonctionnels ;
  6. stopper le traitement en cas d'erreur inattendue. Par exemple lancer une exception afin d'annuler la transaction par la suite ;
  7. valider ou annuler la transaction en fonction du résultat du traitement ;
  8. retourner le résultat du traitement au Contrôleur.

Le rôle du Modèle consiste à traiter l'information reçue. Après le traitement, il peut envoyer ou non un résultat, ou indiquer qu'une erreur est apparue au cours de son exécution. C'est le seul contrat que le Modèle doit honorer avec son appelant : le Contrôleur ou autre (test unitaire).

La Vue - View

Vue - View

La Vue est la partie visible de l'iceberg. Son rôle est d'afficher les données résultant du traitement du Modèle. La Vue récupère ces informations depuis le Contrôleur, formate les données si besoin puis construit la présentation avant de la renvoyer au Controller. Cette présentation, ou la réponse à la requête doit être sous le format de données attendu par l'utilisateur (client). Par exemple :

Tout comme le Modèle, la Vue a aussi un engagement envers le Contrôleur. La Vue reçoit des données brutes du Contrôleur. Ces données sont manipulées dans le but d'obtenir une réponse formatée attendue par le client.

Le Contrôleur récupère cette réponse. Il ne se soucis guère du format ou de ce qu'elle peut bien contenir. Le Contrôleur se contente tout simplement de renvoyer le résultat de la Vue à l'utilisateur.

Conclusion

L'architecture MVC offre un cadre normalisé pour le développement, une bonne pratique devenue une philosophie pour bien structurer une application, séparer les problématiques, optimiser la coordination et la communication entre les différents corps de métier (concepteur, développeur, DBA, intégrateur...).

Des frameworks (cadres de travail) s'inspirant du MVC sont apparus, industrialisant tout ce qui est possible d'automatiser, c'est-à-dire les parties techniques redondantes, telles que :

Ainsi, grâce au design pattern Model-View-Controller, les développeurs ne se soucient plus de la technique. Ils ne se concentrent que sur les aspects fonctionnels du métier, du développement des composants métiers et de la conception de la base de données.

Le MVC ne prétend pas être la solution à tous les problèmes, mais montre une voie sur la façon dont ces problèmes peuvent être traités rapidement et avec efficacité.