Design pattern : MVC

Le pattern MVC est l’un des patterns les plus connu du monde de l'ingénierie logicielle. Celui ci est peut être même le représentant et le plus emblématique de la notion de pattern de conception. Cependant ce pattern a beau être le plus connu, il est aussi probablement l'un des plus complexe et des plus diversifié dans ses implémentations.

Ce pattern MVC est avant tout un pattern de conception. Il a ensuite été généralisé en tant que pattern d'architecture mais aussi adapté (pour ne pas dire déformé) pour des contextes de conception et de réalisation un peu plus éloigné de son objectif initial.

Dans son principe, et nous l'avons déjà souvent vu avec les autres pattern, le pattern MVC mène lui aussi à la separation des preoccupations en s'attachant à traiter la problématique de l'indépendance des interfaces homme machine (et de ses interactions) et des composantes métiers du logiciel. Bien sur, si cela a été son but initial, aujourd'hui son utilisation a plus de cadre d'application que cela, et de nombreuse déclinaisons sont possibles tant que le soucis de découplage est présent au sein d'entités communicantes de façon cyclique (nous allons voir rapidement pourquoi).

Ainsi pour procéder a ce découplage, MVC propose de découpler la solution logicielle en 3 entité distinctes que sont le Modèle, la Vue et le Controller (d'où MVC... héhé!).

Je vais éviter de faire des paraphrases sur le rôle de ces différents éléments mais malgré tout je n'utiliserai pas non plus d'exemple pour illustrer ces concepts car cela dénaturerait l'objet initial de ce pattern qui a la base ne définit pas spécifiquement de moyen d'implémentation. Dans l'explication qui sera donnée, on pourrait aussi avoir l'impression que nous définissons les choses sur la base des autres définition donnant l'impression d'une explication un peu cyclique mais dans le principe, le MVC est cyclique donc... finalement c'est normal.

Le concept de modèle dans le MVC peut être vu (dans un premier temps car en fait non mais ca peut etre plus simple de prime abord expliqué ainsi) comme l'élément pivot du pattern. Le modèle concentre l'ensemble des informations qui seront nécessaires à la vue. Première confusion possible, le modèle n'est pas le modele metier de votre application, il n'est que le modèle de la vue et des informations qui devront y être exposé. C'est subtile mais important nous verrons pourquoi après.

La vue justement est le porteur de l'information graphique, elle définit structurellement la manière dont seront agencées les données extraites du modèle et les encapsulant dans des éléments décoratifs spécifiques à la technologie d'interface en se limitant justement au côté affichage.

Le contrôleur prend ensuite le relais justement sur les éléments de la vue susceptible d'être le lieu d'émission d'événements consécutif aux actions de l'utilisateur. Attention, le contrôleur n'est pas derrière la vue ou même dans la vue mais il est la facette événementielle de celle ci permettant la gestion des actions. Bien sûr, nous avons le sentiment que l'action est corrélé avec chacun des éléments de la vue mais cela est dû à une propriété particulière du pattern MVC que nous détaillerons par la suite, la composition. Gardons en tête pour l'instant que le contrôleur a pour rôle d'intercepter les actions utilisateur et en conséquence de quoi d'aller indiquer au modèle qu'une modification est à prendre en compte.

Nous voyons donc que la structure cyclique du pattern MVC est importante. Le modèle renseigne la Vue qui expose les actions possible que le contrôleur va intercepter et solliciter le modèle pour sa mise à jour qui du coup va permettre à la vue de se mettre à jour.

Structurellement on a compris comment cela fonctionne. Cependant nous n'avons pas parler de comment le pattern va s'implementer. Pour implementer le pattern MVC, il est important de comprendre que sa préoccupation principale est le découplage, que ce soit bien sur des aspects représentations, contrôle ou gestion des données mais aussi et surtout au niveau de la granularité. Ainsi ce pattern n'est pas forcément contraint de fonctionner en trinôme. Pour un même modèle, plusieurs vue peuvent exister, celle représentant l'information a sa manière et avoir en conséquence des contrôleurs spécifiques pour chacunes d'elle ou pas si l'action résultant est finalement la même (on pourrait imaginer des boutons tous différents mais ayant la même finalité....) De même un pattern MVC peut aussi être une composition de pattern MVC permettant par exemple une gestion coordonnées de fenêtre et de taille. On remarque justement très bien ici que pour plusieurs modèles et vues (éventuellement encapsulé les unes dans les autres) on n'aurait qu'un seul contrôleur. Ainsi les possibilité sont réellement très grande tant le découplage de ces aspects facilite les combinaisons de comportements.

Maintenant que nous avons vu de quoi le pattern retourne, nous pouvons traiter de son implémentation et des limites que ces dernières imposeront. Initialement le pattern MVC est apparu avant l'explosion du Web dans le langage smalltalk (une merveille d’ailleur… dommage…)Il a ensuite été consolidé sur les interfaces graphiques des clients Lourd comme AWT ou swing. Ainsi, le pattern MVC s’est défini principalement sur le pattern observateur ou chaque élément de pattern MVC est observateur d’un élément mais aussi observé par un autre élément. Ainsi, la vue est observateur du modèle qui est observateur du ou des contrôleurs (ces derniers étant indirectement les observateurs de la vue en interceptant les événements). C’est ainsi grâce à l’observateur que le pattern MVC tire non seulement ce découplage mais aussi sa réactivité.

Ce modèle du MVC a longtemps été le standard de ce pattern et on le retrouve implémenté sous cette forme dans la plupart des frameworks graphiques standard. Cependant avec l'expansion du web, et la mise en communication de plus en plus forte des interfaces clientes (appelé front) avec les couches server (appelé back), il a fallu trouver un moyen efficace de rationaliser la conception des IHM et leur communication avec le métier. Ainsi de façon naturelle et évidente, et comme elle avait fait ses preuves, on s’est naturellement tourné vers le pattern MVC.

Ainsi, le pattern MVC est aujourd’hui encore largement répandu, souvent vendu comme une nouvelle approche alors que vieille comme le monde, l'élément neuf étant surtout la façon de le mettre en oeuvre. On peut évoquer par exemple les approches des Framework JEE (avec le duo Servlet/JSP), le framework Spring MVC ou Django.

Nous reviendrons sur ces implémentations dans des articles dédié mais ces frameworks usent d’une implémentation spécifique de MVC et de la même manière, d’autres variantes existes comme le modèle MVP (Modèle Vue Présentateur, qui va impliquer la mise en place du présentateur entre la vue et le modèle afin de préparer les données) ou encore le modèle MVVM, porté par microsoft pour son framework silverlight, qui cherche lui aussi à découpler la vue du modèle des données de représentation.

Bien sur ce pattern reste riche et est toujours le sujet de nombreuse recherche. Il est important de bien le connaître afin de savoir non seulement le reconnaître dans ses différentes déclinaison mais il faut aussi savoir l’utiliser dans des contextes où on ne l'attendait pas forcément car s’il est catalogué dans les pattern dédié au IHM, ses principes de bases sont le découplage (pour preuve de l’utilisation massive de l’observateur sur lequel il repose essentiellement) et son utilité dans d’autre couche logiciel ne fait aucun doute (surtout pour concevoir des logiciels réactifs…..)

Références:

[1] https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm
[2] http://www.msdotnet.co.in/2015/05/difference-between-mvcmvp-and-mvvc.html#.Wsf2RZ9fihc
[3] http://www.interaction-design.org/references/conferences/interact_87_-_2nd_ifip_international_conference_on_human-computer_interaction.html#objectType_journalArticleInConfProceedings__objectID_7547