Le weblogue de SeB

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.

Principe

Un modèle à trois couches

Le MVC 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 coeur 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

MVC model 2

Le MVC très pratique, peut se révéler lourd à mettre en place. Ceci à cause de la multitude de contrôleur à 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.

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 facilite 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 interchangé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 microcomposant 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.

conception mvc

Cet article a été publié le Jeudi 9 décembre 2004 à 19:56 et est classé dans Conception. Vous pouvez en suivre les commentaires par le biais du flux RSS 2.0. Vous pouvez laisser un commentaire, ou faire un trackback depuis votre propre site.