Le Model-View-Controller (MVC) est un modèle de conception logicielle très répandu et fort utile. Créé dans les années 80 par Xerox PARC pour Smalltalk-80, il est aujourd’hui fortement recommandé dans l’univers J2EE. Néanmoins il faut retenir que c’est un modèle de conception, et il est donc indépendant du langage de programmation.

Sommaire

Principe du Modèle Vue Contrôleur

Un modèle à trois couches

Le MVC (Modèle Vue Contrôleur) est un modèle de conception qui repose sur la volonté de séparer les données, les traitements et la présentation. Ainsi l’application se retrouve segmentée en trois composants essentiels :

  • le modèle
  • la vue
  • le contrôleur

Chacun de ces trois composants a un rôle bien défini.

Le modèle représente les données et les règles métiers. C’est dans ce composant que s’effectuent les traitements liés au cœur du métier. Les données peuvent être liées à une base de données, des EJBs, des services Web, … Il est important de noter que les données sont indépendantes de la présentation. En d’autres termes, le modèle ne réalise aucune mise en forme[1]. Ces données pourront être affichées par plusieurs vues. Du coup le code du modèle est factorisé : il est écrit une seule et unique fois puis réutilisé par chaque vue.

La vue correspond à l’IHM. Elle présente les données et interagit avec l’utilisateur. Dans le cadre des applications Web, il s’agit d’une interface HTML, mais n’importe quel composant graphique peut jouer ce rôle.

Le contrôleur, quant à lui, se charge d’intercepter les requêtes de l’utilisateur, d’appeler le modèle puis de rediriger vers la vue adéquate. Il ne doit faire aucun traitement. Il ne fait que de l’interception et de la redirection.

Cinématique

  • L’utilisateur émet une requête
  • Le contrôleur intercepte la requête de l’utilisateur
  • Le contrôleur détermine quelle partie du modèle est concernée et quelle vue y est associée
  • Le modèle traite les interactions avec les données, applique les règles métier et renvoie les données au contrôleur
  • Le contrôleur sélectionne la vue et lui renseigne les données
  • La vue présente les données à l’utilisateur

Diagramme du Modèle Vue Contrôleur

MVC model 2

Le MVC très pratique, peut se révéler lourd à mettre en place. Ceci à cause de la multitude de contrôleurs à implémenter. Afin de simplifier la réalisation d’un tel modèle, une nouvelle version a été introduite : le MVC2. C’est exactement le même modèle de conception à la différence qu’il n’y a plus qu’un seul contrôleur qui se charge de rediriger la requête vers le bon traitement.

Le MVC, dans la pratique

Avantages

A l’époque des applications Web, il n’est pas rare que le développeur soit tenté de mettre du code de traitement dans les composants de présentation (JSP, PHP, …). Certains composants facilitent même ce genre de développement!! Le MVC impose cette séparation.

Comme précisé plus haut, plusieurs vues peuvent utiliser le même modèle. Ce qui représente un gain en coût de développement important.

Le modèle est totalement indépendant de la vue. Si l’application a besoin d’un nouveau mode d’accès, le modèle restera inchangé. Il suffit juste de changer la partie IHM.

Le modèle étant totalement autonome, il peut être modifié beaucoup plus facilement. En effet si le mode de persistance des données change ou bien si des règles métier évoluent, il suffit de modifier seulement le modèle. La vue n’a pas besoin d’être modifiée dans ce cas.

Deux équipes peuvent travailler en parallèle. Une équipe d’infographistes peut travailler sur les vues et en même temps une équipe de développeurs peut travailler sur le modèle et le contrôleur. Cet aspect nécessite tout de même une bonne communication entre les deux entités.

Les trois couches doivent être réellement indépendantes et ne doivent communiquer que par des interfaces. Dans ce cas l’application sera très modulaire et n’importe quelle couche pourra être inter-changée sans conséquence pour les autres.

Le contrôleur permet une très grande souplesse dans l’application. C’est lui qui assemble différentes parties du modèle avec une vue à partir d’une requête. S’il est maitrisé à  la perfection, la factorisation des vues est envisageable. L’architecte peut alors s’amuser à en surprendre plus d’un développeur!!

Inconvénients

Le MVC se révèle trop complexe pour de petites applications. Le temps accordé à l’architecture peut ne pas être rentable pour le projet.

Même si le code est factorisé, le nombre de micro-composants n’en est pas moins augmenté. C’est le prix à payer pour la séparation des 3 couches. Et toutes les personnes qui font de la gestion de configuration comprendront que le nombre important de fichiers représente une charge non négligeable dans un projet.

Conclusion

Le MVC favorise le développement et la maintenance du code. Sur de gros projets et/ou avec de grandes équipes de développements, l’application d’un tel modèle de conception se révèle très performant. Il existe aujourd’hui des frameworks très avancés qui se basent sur le MVC ou le MVC2. L’utilisation de ces frameworks facilite sa mise en place et cadre sa réalisation.

Pour les personnes qui souhaitent mettre en place une application MVC2 en J2EE, Struts se révèle très adapté.

Notes

[1] C’est souvent ici que le bât blesse.

https://blog.lecacheur.com/wp-content/uploads/2004/12/tumblr_nhrpjyUYI51sfie3io1_1280-1024x742.jpghttps://blog.lecacheur.com/wp-content/uploads/2004/12/tumblr_nhrpjyUYI51sfie3io1_1280-150x150.jpgSeBConceptionLe Model-View-Controller (MVC) est un modèle de conception logicielle très répandu et fort utile. Créé dans les années 80 par Xerox PARC pour Smalltalk-80, il est aujourd'hui fortement recommandé dans l'univers J2EE. Néanmoins il faut retenir que c'est un modèle de conception, et il est donc indépendant du langage...Un blog, c'est un blog !