Dot.Blog

Le pattern MVVM j’en parle assez souvent ici, même au travers de très gros articles à télécharger. Je vous ai déjà présenté plusieurs façons d’appliquer ce pattern juste en Csharp/Xaml ou bien avec des librairies comme MVVM Light. Il est temps de faire un point sur la mise en pratique. Peut-on aller plus loin dans le “light” ?

Une question bête

En fait, aucune question n’est bête, seules certaines réponses le sont...

<attention cet article date de 2011 et représente un instantané de cette époque - des notes récentes ont été ajoutées en 2015. Cet article avait besoin d'une révision après si longtemps !>

Mais après tout ce temps passé à comprendre moi-même, puis à appliquer et à expliquer aux autres la pattern MVVM, il me vient comme ça, une idée saugrenue : ne peut-on faire plus light ? MVVM est-elle la bonne solution, ou plus exactement : MVVM est-elle la solution à un vrai problème ?

Hérétique non ?!

<note: C'était la grande époque de Silverlight. WPF n'avait toujours pas réussi à convaincre là où SL séduisait de plus en plus de développeurs>

Retour d’expérience

Pourquoi cette question ? Parce qu’à force de côtoyer MVVM, de l’utiliser dans des tas d’applications et d’en parler en long, en large et en travers (mais j’espère jamais de travers !), j’en aperçois certains défauts.

Et comme je suis franc, je vous livre ici mon sentiment “d’expert”, MVVM même avec une librairie hyper light comme MVVM Light, je trouve ça utile, nécessaire, mais lourd.

Même en restant le plus léger possible j’entrevois plusieurs problèmes dont les principaux qui me viennent à l’esprit en écrivant :

• le dialogue entre les ViewModels
• le traitement des dialogues avec l’utilisateur
• Et un constat : beaucoup des avantages justifiant MVVM ne sont pas utilisés en pratique.

Dialogue entre les diverses parties de l’application

Je disais dialogue entre ViewModels mais on peut même parler en général du dialogue entre les différentes parties de l’application. Par exemple entre la ViewModel et sa Vue.

Comme vous le savez, une gestion de message devient vite indispensable pour respecter le pattern. MVVM Light propose une classe Messenger à cet effet, d’autres librairies utilisent des procédés plus ou moins équivalents comme l’EventAggregator de Caliburn.

Créer des messages, les typer, leur donner des noms, créer les gestionnaires qui reçoivent les messages, ne pas se prendre les pieds dans le tapis entre tous les messages qui transitent devient en réalité très vite une prise de tête, voire un parcours d’équilibriste... Car cette partie là n’est guidée par aucun pattern, aucune méthodologie qui en clarifierait l’application. Mais c’est une partie indispensable à la mise en œuvre de MVVM.

Le modèle “classique” qui permet d’appeler directement le code dont on a besoin est autrement plus clair et pratique (et plus maintenable pour des équipes rompues à Windows Forms). L’abstraction de ICommand reste malgré tout intéressante. Mais les messages qui permettent d’éviter le couplage fort pour le moindre évènement, cela n’est pas assez clairement codifié.

En tout cas cette histoire de messages assez peu structurés qui se trimbalent dans tous les sens pour la moindre chose ajoute une lourdeur certaine et une complication évidente aux applications surtout dès que le nombre des messages échangés devient grand et que les différentes natures de messages se multiplient au passage. Il faudrait les limiter, y mettre des guides pour les réserver à certaines utilisations, ce que MVVM ne précise pas laissant chaque librairie inventer sa solution.

<note: d'où la nécessité de structurer les messages MVVM, de les documenter, de placer les chaînes de notification dans des constantes appelées depuis un point centralisé, etc. Le problème n'est donc pas tant les messages que la bonne façon de s'en servir !>

Les dialogues utilisateur

Ici je parle des dialogues au sens UI du terme, c’est à dire des choses aussi simple qu’afficher une confirmation “oui/non” ou “ok/cancel” sur une action. J’inclue bien entendu et a fortiori tous les autres types de dialogues plus complexes, les fenêtres de demande d’information, etc.

Là encore le circuit se complique. Le déclenchement du traitement est fait le plus souvent par la Vue (l’utilisateur) qui doit exécuter une commande se trouvant dans le ViewModel, mais comme ce dernier n’a pas le droit de voir sa vue (kafkaïen) pour demander une simple confirmation à l’utilisateur il faudra développer tout un tas de ruses, et une fois encore passer par la fameuse messagerie (en sauvegardant un éventuel contexte pour traiter la réponse, un autre message ou un callback, s’il arrive un jour). Il arrive aussi qu’un dialogue soit initié par un ViewModel. Et là, tout seul, isolé de l’utilisateur et de l’UI, c’est encore tout un manège complexe qu’il faut mettre en place pour lui permettre d’accéder enfin à l’utilisateur.

Je trouve cela affreusement complexe, malaisé, difficile à maintenir et peu compréhensible quand on lit le code d’un autre, ou le sien quelques semaines ou mois après.

<note: heureusement l'arrivée de async/await sous csharp a permi de clarifier cette gymnastique ainsi que la prise en charge de services de dialogues par de nombreux frameworks. Preuve en est que mes remarques de 2011 pointaient des problèmes réels. Il fallait avoir la foi dans le temps qui passe et qui améliore les choses, c'est tout !>

Des avantages fantomatiques

Un autre truc me chiffonne dans l’application de MVVM : sa justification se trouve principalement (mais pas seulement heureusement) dans une poignée d’arguments (ou avantages) dont on ne se sert jamais en réalité.

Par exemple, le fait qu’on puisse fournir un ViewModel totalement différent à une Vue sans avoir à la modifier, ou l’inverse. C’est un gros avantage, mais à ce jour je ne l’ai personnellement jamais utilisé ni n’ai eu besoin d’un tel artifice. La Vue n’est pas une pure abstraction d’artiste, elle “colle” au fonctionnel. Idem pour le ViewModel, il prend en charge les commandes (boutons ou autres) d’une Vue particulière. Si on le lie à une Vue différente, il y a de fortes chances pour que cela ne marche pas... Dès lors la Vue et son ViewModel sont en réalité très liés. Conceptuellement mais aussi en termes de contenu (visuel lié à l’existence d’un certain code d’un côté, code dépendant de certains éléments visuels de l’autre).

Si la Vue ne convient pas, elle sera ré-designée. Mais pas besoin de séparation Vue/ViewModel pour corriger une page Xaml. Finalement que le code soit dans le code-behind ou dans un ViewModel, cela ne change rien à l’affaire. De même, si les traitements du ViewModel ne conviennent pas ou sont bogués, le code sera modifié, qu’il se trouve dans le code-behind ou le ViewModel ou bien plus classiquement dans une couche BOL par exemple.

L’avantage dans la pratique n’est donc pas si évident.

Autre argument : Les développeurs peuvent créer le code et le tester sans que la Vue n’existe. Variante : le Designer peut travailler sur la Vue indépendamment des développeurs.

Sur le papier c’est génial. Mais le premier point c’est que rares sont les projets où il y a un vrai Designer... Le second point c’est que dans cette même réalité le Designer ne travaille jamais “en l’air”, il a besoin du code, au moins du code de Design avec données fictives, simulation des états réels de la Vue, Converters, etc. A moins de développer en plus un ViewModel fictif mais très réaliste puis ensuite seulement un “vrai” ViewModel fonctionnel, ce que je n’ai jamais vu faire étant donné le surcout, autant donner le travail au Designer une fois le ViewModel au point (même s’il reste des détails de programmation à régler).

Le Designer, c’est un job bien particulier, qui, hélas, n’est que fort peu pourvu en vrais détenteurs du titre... Ne parlons pas du fait que les employeurs sont très réticents à payer à l’année un gugusse juste pour travailler sur le look de deux applications et aller à la pêche le reste du temps... Ces mêmes employeurs sont déjà difficiles à convaincre, en tant que client, lorsqu’on ajoute des journées de Design au chiffrage d’un projet ! On en vient à faire du Design gratuitement, comme une “démo”, comme un teasing, espérant que les mentalités évoluent. Mais cela n’est pas un problème, c’est le sens de l’histoire et ces gens y viendront inéluctablement. On ne peut vivre dans un monde où même votre concierge à un IPhone et continuer de faire des applications au look XP.... Mais encore faut-il que le métier de Designer en informatique soit reconnu et que de vraies formations à ce métier se terminent par de vrais diplômes.

Or, pour l’instant on a le plus souvent affaire à des infographistes bricolant un peu le Web ou bien des informaticiens un peu artistes. Quant au rôle de “l’Intégrateur” que le pattern MVVM fait apparaitre comme un troisième métier et un passage obligé, il est en fait tenu soit par le graphiste s’il s’y connait un peu en développement ou bien par l’informaticien car il est celui qui connait le mieux le code et que relier du visuel à son code n’est pas tâche si complexe. Et puis, encore une fois, je ne connais aucun patron qui va payer un troisième salarié pour faire l’intermédiaire entre Designer et Développeur... L’Intégrateur est mort-né, le rôle est joué par les deux autres... Encore un avantage de la pattern qui s’évanouit...

Du coup, créer toute application sans aucun visuel puis confier le Design à un vrai Designer, c’est une chose que je n’ai jamais vu faire. Pas plus qu’un Designer qui créerait une interface géniale pour un code qui n’existerait pas. Il peut concevoir une maquette visuelle avant que le code n’existe, cela se pratique, c’est le modèle Design-driven ou Design-First à la Apple, mais coder une Vue sans le code qui va avec, non. Pas plus qu’un Designer travaillant seul, éloigné des développeurs car il y a mille détails qui réclament si ce n’est un travail totalement en commun au moins une communication fréquente entre les deux parties. Ou bien on est sur des choses très très simples, pas de vraies applications. Maintenir un pattern pour une situation qui n’est que fantasmer n’a que peu de sens on en conviendra.

Reste la possibilité de tester le code par du Unit Testing sur les ViewModels totalement automatisé sans passer par les Vues. C’est super pratique et très futé. Mais là encore, un logiciel qui marche, ce n’est pas seulement un code qui tourne rond, mais l’ensemble “code + UI” qui doit coller au cahier des charges. Rien n’interdit le Unit Testing systématique, cela est même vivement conseillé, mais le code-behind et la séparation “classique” des layers (DAL, BOL...) ne l’interdit pas bien au contraire ! Et des outils d’automatisation de l’UI aux fins de tests sont même fournis par Microsoft pour “rejouer” des séquences manuelles sur l’interface si cela s’avère nécessaire. L’avantage semble donc ici encore bien mince.

Mais revenons à la réalité, combien d’équipes utilisent ce type de tests sophistiqués ? Combien de projet disposent-ils du budget ad hoc ? Même le simple testing sur des applications très classiques reste une exception plus qu’une règle suivie systématiquement ! Soyons réalistes... Le prix. toujours ce critère industriel auquel l’informatique n’échappera jamais. Entre deux voies, l’une chère, l’autre moins, un dirigeant, un DI, un client, choisira toujours la seconde. Surtout quand les avantages vantés pour la solution la plus chère ne lui semblent pas spécialement percutants (pas de nouvelles fonctionnalités, tout l’avantage est technique et propre à la création du logiciel, ce qui amène la question du client : “mais avant vous me faisiez de la m* alors ? non ?! bien alors continuons comme avant !”).

Dès lors, ces deux avantages là aussi paraissent bien minces mis en face du surcroit de travail qu’ils imposent et du peu d’attraits qu’ils ont pour celui qui paye.

<note: tout cela était très pertinent et reste vrai aujourd'hui. Mais il n'est pas question de remettre en cause la séparation View/ViewModel, le code-behind ne peut remplacer un code séparé comme le ViewModel et on lui trouve même une autre utilité : séparer le code qui manipule l'UI du ViewModel (adapter une taille d'objet visuel, etc). Mais ce n'est pas pour rien en revanche si par exemple Mvvm Light abandonne progressivement le ViewModelLocator. Le ViewModel peut être directement lié à la Vue par une ressource. Encore une fois le temps a permis de faire le tri entre le superflu et l'indispensable.>

Constat d’échec ?

Non, je ne le pense pas. Mise en œuvre laborieuse, librairies non unifiées, langages et outils non conçus dès le départ pour le pattern, en revanche oui.

Je crois aussi que dans notre profession certains ne pensent qu’aux problèmes de façon abstraite sans se soucier de savoir si les équipes d’informaticiens qui travaillent au quotidien sur la majorité des logiciels produits dans le monde rencontrent réellement ces problèmes. Dès lors on se met à trouver des solutions idéales à des problèmes purement théoriques... MVVM est en partie une solution de ce type. C’est une bonne solution mais à des problèmes qui ne se posent pas vraiment tous les jours à la majorité des informaticiens ou de leurs employeurs... Pire, elle induit par sa présence de nouveaux problèmes bien concrets qui ne trouvent pas de réponse.

En parler, comme je le fais ici, peut même sembler totalement blasphématoire et hérétique tellement MVVM, MVC ou leurs cousines s’imposent comme “la voie royale” pour créer de “bons logiciels”. 

<note: en 2011 ce constat était justifié. Avec le temps nous avons appris à laisser de côté les fausses solutions de MVVM et à nous concentrer sur son véritable apport : le découplage>

De plus MVVM coûte cher à appliquer. C’est un constat que je ne peux renier et que j’estime à 40% de surcoût au minimum et jusqu’à 100% dans certains cas (voire même encore plus sur les petits projets).

Comme je suis un maniaque de la maintenabilité je suis aussi forcément déçu par le résultat qui, au lieu de tout simplifier, complique inutilement des choses simples. Surtout si ça coûte plus cher.

<note: magie de l'expérience accumulée, aujourd'hui développer en MVVM ne représente qu'un surcoût très léger qui économise beaucoup de problèmes plus chers>

Soit c’est le client qui paye, mais le prix devient exorbitant, soit c’est la société qui développe qui supporte seule le surcoût et cela peut la tuer... On sait bien que les SSII ont presque totalement banni le “forfait” de leurs pratiques pour éviter ce genre de risque. Donc aujourd’hui c’est le plus souvent le client qui paye, sans trop s’en rendre compte, grâce à la “régie”, du travail temporaire qui ne dit pas son nom, mais qui arrange tout le monde (la SSII ne se mouille pas, le client n’augmente pas sa masse salariale ce qui représente plein d’avantages). L’informaticien est souvent le dindon de la farce d’ailleurs, mais c’est une autre histoire.

<note: cette problématique peut se généraliser à tout travail de réalisation d'un logiciel. MVVM pas plus qu'UML ou d'autres méthodologies permettant de rendre les logiciels plus fiables comme le Testing ne sont coupables. Les clients veulent toujours payer moins pour un produit de plus en plus sophistiqué. Cela ne change pas en effet, mais ne doit pas servir à démonter l'inutilité de ces avancées méthodologiques...>

Faut-il oublier MVVM ?

En cette période de grande mode des patterns de même type (MVC et autres) la question peut paraître blasphématoire. Mais j’ai toujours eu la réputation d’un trublion posant certes les bonnes questions mais au mauvais moment... Alors...

Comme je me fiche du politiquement correctement, j’ose poser la question.

Honnêtement, le pattern MVVM est très séduisante. Au moins intellectuellement. Elle impose un découpage des responsabilités qui ne peut que clarifier les choses. Mais voilà, tout cela a un prix, et, de plus, suivre le pattern à la lettre tend à créer des logiciels plus lourds et moins maintenables, l’inverse de ce que promet ce pattern. Un comble donc.

<note: mal maîtrisé, MVVM complique les choses, cela reste vrai aujourd'hui. L'expérience a permis de dompter le pattern et son application pour un résultat plus maintenable. Il fallait du temps et se poser justement toutes les questions abordées ici pour que langages et frameworks évoluent dans la direction d'une simplification.>

Il faut bien que quelqu’un brise le silence. Quand dans notre métier une technique est à la mode, même si tout le monde souffre dans son coin, personne n’ose le dire de peur de passer pour un idiot.

Je viens vous soulager, je serai cet idiot là !

Il en faut bien un, le premier qui pose la question. C’est après que d’autres disent “ah oui, c’est pas faux...” !

Et comme j’ai largement prouvé ma connaissance approfondie du pattern par des tas de billets, d’articles et de réalisations, personne ne dira que je critique quelque chose que je ne comprends pas ...

Et c’est justement avec cette connaissance de MVVM et surtout avec sa pratique que j’aurais donc tendance à dire “oui, on stoppe tout, on revient à l’étape précédente et on réfléchit à quelque chose de plus réaliste”.

<note: réaction un peu forte, heureusement adoucie quelques lignes après !>

Mais MVVM n’est pas le diable non plus alors je ne serai pas aussi radical. Même si la plupart de ses avantages n’apparaissent pas dans les faits, un seul avantage mérite à lui tout seul d'appliquer MVVM : le découplage fort.

<note: MVVM ne devait pas se limiter aux seuls gros projets, croyance de l'époque faussée par le surcoût occasionné. MVVM s'applique même aux petites applications pour smartphone, et même aux jeux aujourd'hui !>

Par exemple, combien de projets méritent qu’une équipe de Designers totalement indépendante travaille sur une interface sans le code ? Combien de projets nécessitent que le code soit totalement écrit sans aucun visuel ? Combien de fois dans un projet aura-t-on besoin de changer totalement une Vue et d’en accrocher une nouvelle à un ViewModel existant sans modifier ce dernier ? Dans combien de projets écrit-on des variantes des ViewModels qui sont ré-aiguillés par un ViewModel Locator ? Combien de fois du Unit Testing sera fait en temps et en heure uniquement sur le code sans tester le visuel en même temps ? etc...

<Note: cela reste vrai. Toute une partie de MVVM n'a aucun sens dans la réalité. Mais il ne faut pas se focaliser sur cette partie là. D'autres apports essentiels justifient à eux seuls d'appliquer le pattern malgré ces "faux avantages" qu'on mettait en avant à l'époque et dont on ne parle plus ou presque il faut l'avouer.>

Doit-on tout rejeter de MVVM ?

Non. Il y a de très bonnes idées derrière cette pattern. Un “style” qui force à une certaine séparation, un découpage qui reste attrayant et canalisateur du travail.

Alors peut-on faire plus light et se débarrasser des inconvénients de MVVM tout en gardant ses avantages ?

MVVM Ultra Light

Je pense que pour la majorité des projets de petite taille ou de taille moyenne on peut (on doit ?) utiliser une version “ultra light” de MVVM.

Il ne faut pas abandonner le pattern, il faut juste l’adapter à la réalité.

Tout d’abord il est nécessaire de re-clarifier les rôles.

“Modèle-Vue-Modèle de Vue”, c’est MVVM. Mais personne n’a dit que cette pattern annulait et remplaçait le découpage DAL / BOL / Interface.

De fait, “Modèle” dans MVVM ce n’est que le DAL dans l’ancien découpage. Un simple changement de terminologie ? Oui et non. Oui car parfois Model = DAL, et parfois le DAL est tellement sophistiqué qu'il est préférable de conserver une séparation avec une couche Model qui en simplifie l'accès. L'esprit du découplage doit régner en maître...

Mais le BOL ? il devient quoi ? Soit il existe toujours et de fait le ViewModel ne devient qu’une sorte “d’adaptateur” du BOL pour la Vue, soit on a tendance à transférer le BOL dans les ViewModels ce qui n’est pas une bonne idée.

Il faut donc restaurer la place du BOL, au dessus du DAL, qu’on soit en MVVM ou non.

Du coup le ViewModel ne contient plus aucune logique métier. Il ne sert qu’à adapter cette couche à une Vue précise.

<note: cela est essentiel et c'est ainsi qu'on doit appliquer MVVM aujourd'hui. Ce conseil était donc bien vu !>

On retrouve ainsi une pattern qui s’écrirait plutôt : DAL / BOL / ViewModel / Vue

Mais on sait aussi que MVVM n’interdit pas les liaisons directes Modèle-Vue pour “les cas simples”. Elle n’interdit donc pas les liaisons DAL/Vue, ni BOL/Vue si le BOL fournit lui-même des données en cachant la réalité du DAL. Exit le ViewModel dans tous ces cas.

Que reste-t-il au ViewModel alors ? Juste un élément de complication qui impose une messagerie et une gestion de commande pour gérer le click des boutons et les boites de dialogue ? !

En fait, le vrai rôle du ViewModel est de gérer les états spécifiques d’une Vue et d'adapter les données entre le Model et la Vue.

Mais ce rôle là, c’est justement celui du code-behind à l’origine !

<note: c'est parfaitement vrai et parfois pour faire du MVVM rapidement et sans Framework on utilise cette astuce. Mais en production on préférera conserver l'avantage d'un découplage fort qu'offre le ViewModel.>

Autre point, prenons pour exemple l’indirection du ViewModel Locator dans MVVM Light (mis en œuvre autrement ou sous d’autres noms (comme l’Injection de Dépendances, qui implémente lui-même le principe d’Inversion de Contrôle). Dans les faits on se sert pas des avantages qu’il est censé procurer. Il complique le lien entre Vue et ViewModel, il peut être supprimé. La Vue étant liée directement dans son entête (via son DataContext) à son ViewModel au lieu de passer par le Locator. Un intermédiaire de moins.

<note: Bien vu! Même MVVM Light abandonne le ViewModelLocator progressivement. La méthode que je proposai est donc celle qui est la plus directe, la plus simple, et qui évite des complications inutiles.>

Mais ce ViewModel, dénudé de tout ce qui est à la charge du DAL et du BOL, qui se trouve lié spécifiquement à une Vue, ne fait-il pas double-emploi avec le code-behind qu’on s’évertue à laisser absolument vide sous MVVM ? Le simple fait de ne pas utiliser ce code pourtant lié à la Vue implique toute la gymnastique des messages et des lourdeurs déjà évoquées.

Ne serait-il pas plus raisonnable, et c’est juste à ce point une question de nom, de dire que le code-behind est le ViewModel ?

Dès lors tout se simplifie... Plus besoin de messagerie complexe pour afficher un “ok/cancel”, plus besoin de Locator dont l’intérêt existe toujours mais dont on ne se sert pas dans les faits.

Hérésie ou rationalisme ?

<note: les deux mon capitaine ! Cette vision des choses se comprend avec le recul mais faisait abstraction des améliorations qui seraient portées au langage, à .NET et aux frameworks Mvvm. De fait aujourd'hui on conserve bien un ViewModel, le code-behind en revanche sert à manipuler les objets d'UI pour éviter de mélanger ce code à celui du ViewModel qui ne doit rien savoir de l'UI. Avec le temps l'hérésie n'est plus si forte car le rationalisme est justement passé par là pour clarifier les choses et amoindrir les difficultés.>

Un nouveau pattern mieux adapté ?

En réalité MVVM est parfaitement adapté à son but une fois qu'on fait abstraction de ces pseudo-avantages qui n'en sont pas. Débarrassé du superflu, MVVM est un pattern d'une redoutable efficacité qui tend à produire un code fortement découplé propice à une meilleure maintenance et à des tests unitaires plus facilement généralisables.

Dans l'interrogation de l'article initial il y a avait ce besoin de sortir la tête de l'eau et de chercher une meilleure façon d'appliquer MVVM.

Le temps, les améliorations de .NET, des langages et des bibliothèques MVVM ont fait leur chemin. Influencés pas forcément par mon article, cela sera prétentieux, mais par l'esprit de mon article qui volait au-dessus de la tête de nombreux développeurs qui avaient expérimenté MVVM "à fond" comme moi.

Il n'y a donc pas de nouveau pattern pour remplacer MVVM, mais c'est tout comme. On a gardé le nom et ce qui était intéressant et on ne parle plus de ce qui n'était pas réalistes...

MVVM aujourd'hui c'est un peu un nouveau MVVM en plus light comme je le réclamais à l'époque.

Conclusion

Il ne s’agit pas ici de réinventer la roue, encore moins de jeter la pierre à un pattern innocent...

Non, je préfère voir les choses comme un retour d’expérience réaliste pointant les faiblesses de MVVM telle qu’il se voudrait être appliqué aujourd’hui (en 2011), aveuglément et sans prendre la mesure des surcoûts inutiles qu’il entraîne.

Et comme j’aime être constructif, quitte à être hérétique, je propose ici d’adapter le pattern aux véritables contraintes du développement, d’en réduire l’impact négatif, d’en supprimer le flafla qui coûte cher pour aucun avantage réel, mais d’en garder l’essence, l’esprit qui en fait l’intérêt.

C’est une réflexion à voix haute. Je n’ai pas l’imprudence de dire que ce que je propose ici est totalement “fini”, je veux seulement ouvrir une voix de réflexion, briser une sorte d’omerta et débloquer une situation en donnant la parole à tous ceux qui voudront bien compléter, confirmer, infirmer ou simplement apporter leur témoignage à la suite de ce billet.

C’est open, dites ce que vous en pensez !

<note finale: Si ce n'est pas cet article à lui seul qui a fait bouger les choses, c'est l'état d'esprit qui l'animait et qui était partagé par de nombreux spécialistes de MVVM qui s'est propagé au fil des années pour venir modifier lentement à la fois MVVM et son contexte (langage, .NET, bibliothèques...). Et sans ce questionnement ouvertement provocateur peut-être que rien n'aurait changé... En tout cas aujourd'hui MVVM est enfin un pattern lisible et cohérent. Le risque de tomber dans un extrémisme nuisible existe pourtant toujours. Que l'esprit de cet article reste en chaque lecteur : aucun dogme ne peut s'imposer à la raison lorsque celle-ci est choquée par des incohérences. A chacun de choisir et d'adapter en fonction de ses besoins. Ne pas se soumettre et toujours réfléchir. Voilà ce que nous dit cet article in fine ! >

Alors plus que d’habitude, Stay Tuned et Commentez !