MVQuessé? Tellement 1970!

J’ai fait beaucoup d’entrevues dans ma carrière. Pas pour des jobs, mais comme évaluateur technique pour tout ce qui touche aux technologies web et à Java. Une question que j’aimais bien poser aux candidats :

À part le singleton et la factory, nommez et décrivez un patron de conception.

Le plus commun à venir ensuite, c’est MVC (Modèle – Vue – Contrôleur). MVC est un patron de conception architectural conceptualisé dans les années 70 pour faciliter la création d’interfaces utilisateur graphiques (ou GUI pour les intimes). Ce concept a été apporté spécifiquement pour SmallTalk. Aujourd’hui, j’aimerais lancer la discussion avec vous : Connaissez-vous vraiment MVC?

Note : Si vous ne connaissez pas du tout MVC, je vous conseille de lire cette page (ang) avant.

J’ai soif 🍺

La base

MVC en 2018, ça se résume à :

Modèle : Logique d’affaires

Vue : Ce que l’utilisateur voit

Contrôleur : Réagît aux événements de la vue et appelle le modèle.

Jusqu’ici ça va? Le problème avec ça, c’est qu’on oublie de nous dire qui est responsable de mettre à jour la vue. Le contrôleur ou le modèle?

Selon Wikipédia

Wikipédia nous dit (ang) que le modèle devrait mettre à jour la vue. Traditionnellement, la vue enregistrait un observateur sur le modèle afin de se mettre à jour lorsque ce dernier change. Si on prend l’exemple en SmallTalk ou autres outils pour créer les GUI natifs, ça fait du sens que la vue puisse se lier au modèle via un observateur. La vue étant créée dans un langage impératif, c’est donc possible de créer l’observateur.

Par contre, ça devient vite le bordel! Simplement changer la langue de Wikipédia pour consulter la même page, l’explication est différente. On nous dit alors que le contrôleur notifie la vue d’un changement sur le modèle… Évidemment, ça ne doit pas provenir du même auteur!

Selon d’autres gens?

Si vous cherchez ailleurs sur le net, vous trouverez plusieurs autres diagrammes différents pour MVC. Microsoft nous présente un MVC où le contrôleur pointe vers la vue et inverse la flèche entre cette dernière et le modèle. Code Project nous présente un MVC avec un contrôleur intermédiaire qui fait l’interaction entre la vue et le modèle, et je passe le reste. Si vous voulez vraiment être mêlés comme un jeu de cartes, cherchez MVC dans Google image!

Et MV*?

En partant du résultat de recherche ci-dessus, on peut très bien constater qu’MVC est un patron architectural très populaire, tellement qu’il est adapté à toutes les sauces. Je reprends l’exemple de Microsoft ci-dessus, on peut lire :

Strongly-typed views typically use ViewModel types designed to contain the data to display on that view. The controller creates and populates these ViewModel instances from the model.

Mais… le concept de ViewModel appartient pas à MVVM (model-view-viewmodel)?

Reprenons aussi l’exemple sur Code Project ci-dessus aussi, on nous dit :

The controller notifies the model of the user action, possibly resulting in a change in the model’s state. (e.g. controller updates user’s shopping cart).

Mais… le concept de contrôleur-médiateur (ou supervising controller) entre la vue et le modèle, ça appartient pas à MVP (model-view-presenter)?

Avouez que ça vient mêlant! Surtout dans une application web, le modèle n’a aucunement la possibilité d’avertir la vue, sauf peut-être si vous ouvrez un WebSocket entre le navigateur et le serveur. Quelqu’un a déjà vu ça? Qu’est-ce qui en est de MVA (model-view-adapter) ou HMVC (hierachicalmodel-view-controller)?

Ok… STOP!

Si on prend une architecture plus récente et mieux adaptée au web, l’architecture en oignon, on constante que les flèches et le diagramme font beaucoup plus de sens. On part simplement de la vue et on descend jusqu’à la couche d’accès aux données, puis on remonte, mais sans dépendance. Par exemple, un service d’affaires va garder une instance d’un Repository ou DAO, mais pas l’inverse, ce qui laisse les flèches uniquement dans une direction.

Si vous avez déjà vu une application designée comme ça, vous avez sûrement remarqué quelque chose… Qui est responsable de gérer les événements utilisateur? Le contrôleur… Évidemment, ça peut faire du sens si vous vous dites qu’MVC est un patron architectural de présentation, couche représentée ci-dessus par UC. Par contre, on sait que que le modèle, ici représenté par Services, Repository et Domain Model, devrait notifier la vue de tout changement, ce qui est très peu probable.

On sait aussi que si le contrôleur est médiateur entre vue et modèle, on tombe plus près d’un MVP que d’un MVC. Je pousse le concept encore plus loin?

Clean Architecture

L’architecture propre est basée sur l’architecture en oignon, avec quelques différences. Par exemple, on parle de cas d’utilisation au lieu de parler de services d’affaires. Mais regardez attentivement…

Ben joual vert! Je lis vraiment Controller, Presenter, ViewModel et Adapter dans le même diagramme?!

Conclusion

Bon… C’était quoi le but de cet article? Constater une chose. MVC est mort. Point. Les applications d’aujourd’hui étant principalement basées sur les technologies web, MVC n’a plus sa place, sauf pour les crinqués qui font du WPF ou du Swing (et encore)! De plus, il y a tellement mieux! Si on prend l’architecture en oignon, on peut s’assurer que, si c’est bien implanté, notre application va être facile à maintenir et évolutive, principalement parce que l’abstraction entre chaque couche de l’oignon vient les découpler au maximum.

Toi, t’en penses quoi? Hésite surtout pas! Je vais te répondre 🙂 Merci de nous lire chaque semaine, de partager nos articles, de commenter sur les réseaux sociaux et de nous laisser un pouce en l’air. Nous avons la meilleure communauté de programmeurs au Québec!

60

SHARES

Partager sur Facebook

Partager sur Twitter

Suivez-nous!

Share

Share

Share

Share

Share