Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

Faut-il vraiment bruler le pattern MVVM ?

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.
<note: ce constat reste vrai aujourd'hui mais les frameworks s'améliorent>

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 !

Faites des heureux, PARTAGEZ l'article !

Commentaires (34) -

  • Olivier

    20/05/2011 02:14:20 | Répondre

    ATTENTION : Suite à un incident sur le serveur ce post a été détruit. Je l'ai recréé mais les commentaires ont été perdu. N'hésitez pas remettre vos commentaires ...
    De plus les liens twitter et facebook ne sont plus correctes.
    Désolé pour l'incident !

  • paslatek

    20/05/2011 10:46:20 | Répondre

    "Je suis un hérétique ! Brulez-moi !" : j'Adore l'autoflagelation ! Smile

    Plus serieusement je trouve l'article pertinent sur certains points, mais un peu trop extrème.
    Pour moi le VM signifie aussi la "voie du milieu". Cette philosophie dit basiquement qu'il faut prendre le meilleur de chaque et accepter le compromis. Il est vrai que je rencontre des developpeurs qui veulent absolument mettre zéro code behind pour modifier l'interface graphique. C'est illogique ! en plus ils se retrouvent à developper des controles custom pour y coller des DP tout ça pour pouvoir dire j'ai fait du MVVM.
    Donc je te rejoins sur l'aspect de la lourdeur de la messagerie par exemple ou du fait qu'on pense qu'un jour on fera un autre VM pour la même Vue... Ceci dit un bon vieux Locator c'est quand même super pratique !
    Par contre concernant le testing unitaire, je pense que nous avons les même soucis sur d'autres type de projets, nous ne prenons jamais le temps d'ecrire complétement ces tests et surtout de les maintenirs !
    Pour conclure je dirais qu'il faut faire du cas par cas et surtout etre pragmatique. Exercice intelectuel souvent difficile pour nous pauvres humains...

  • lummite

    20/05/2011 12:48:07 | Répondre

    Excellente analyse, osée mais salutaire!

    Encore plus tranchant: MVVM uniquement pour les gros projets.
    Sinon à bannir.

    Car rappelons de nos fondamenteux: Keep It Simple, Stupid
    Trop souvent ce principe est oublié au profit de délire d'architecte.
    Au final, nous nous retrouvons dans des usines à gaz non maintenables, dans le pire des cas, à court terme, dans le meilleur à moyen et long terme.
    Quid du changement d'équipes, qui est le lot quotidien des DSI?
    Comment retrouver du personnel compétent, la croix et la bannière oui!
    Faisons simple et fiable ce qui aura pour conséquence de faire un produit flexible car aisément maintenable et le tout pour pas cher!
    Et ça sera déjà pas si mal.

  • Thomas

    20/05/2011 15:10:20 | Répondre

    Ma faible expérience avec ce pattern et l'analyse (théorique) que j'avais pu en faire est confirmée par cet article (moi content Smile).

    Ca soulève quand même un point plutôt intéressant, et même fondamental selon moi : pourquoi s'ennuyer avec des outils qui sont bons dans certains cas alors qu'on en a pas besoin?

    Typiquement, on se retrouve à faire des choses parcequ'on pense qu'elles sont cools et que c'est à la mode (ça claque en réunion d'en parler) alors qu'elles ne sont pas utiles, voire même handicapantes.
    C'est un peu le combat du réalisme à la KISS versus le réunioniteur qui va blinder ses présentations de buzzwords pour paraitre à la pointe de la technique.

    Le MVVM fixe des contraintes qui sont assez lourdes selon moi et qui doivent réellement être prises en considération avant de commencer à s'amuser avec, mais pour ça faut savoir prendre du recul et vraiment comprendre les besoins en terme d'évolution de l'application, et de l'équipe qui bosse dessus.

    Ceci dit, on peut comparer ça avec l'utilisation qui est faite (en général) des design pattern :
    on a un souci -> on l'adapte tant bien que mal pour qu'il colle à un pattern connu.
    C'est pas trop ça que le GoF présente en into de son catalogue Smile.
    Et ce qui est assez paradoxal, le souci est toujours un souci au final.

    Et aussi, les tests unitaires, qui sont quand même pas mal mis en avant dans les arguments de MVVM, sont je pense assez peu utilisés en entreprise (dans la mienne en tous cas mais je ne pense pas être tout seul) : contrainte de temps, flemme, incompétence dans le domaine.
    Par exemple, ce qui est appelé "test unitaire" chez moi c'est "passer en debug dans le code"...

  • Laurent Bugnion

    20/05/2011 17:56:22 | Répondre

    Ben dis donc, quand tu te mets à écrire, tu ne fais pas les choses a moitie LOL Just un peu dommage de n'avoir le texte qu'en français, ça aurait été intéressant d'étendre la discussion au reste du monde.

    En intro, au risque de te décevoir, cet article n'a (à mon sens) rien de révolutionnaire ou d'hérétique, on a assez souvent des gens qui posent la même question, et des discussions à ce sujet. L'histoire de MVVM commence avec WPF, qui a maintenant plus de 5 ans de vie publique, donc ces discussions ne sont pas nouvelles. En fait le débat revient souvent, parfois avec MVVM, plus souvent avec d'autres méthodes et outils, par exemple IOC, DI, Unit testing etc...

    Pour moi la question se pose comme ça:

    •  Peut-on faire XAML (WPF, Silverlight, Windows Phone 7) sans MVVM: Bien sûr que oui. C'est un peu la même chose que de demander si on peut faire du code sans IOC par exemple. Ce sont des outils, rien de plus, rien de moins.

    •  Peut-on faire des applications sans designer? Oui, mais elles ne seront pas aussi belles.
    •  Peut-on travailler avec un designer sans Expression Blend: Très difficile. Blend est un outil presque indispensable quand on veut faire un UI fidèle aux comps en un temps raisonnable. On peut travailler sans Blend, mais ça ajoute vraiment un surcout à l'application.
    •  Est-ce que Blend est indispensable pour travailler en XAML? Non, mais Visual Studio non plus. Une fois de plus, ce ne sont que des outils. Blend, si on prend le temps de le connaitre, facilite énormément le travail dans le UI.
    •  Peut-on travailler avec Blend sans MVVM: Mouais. Pas génial, vraiment. MVVM (en tous cas l'implémentation que j'en fais dans MVVM Light) est optimisée pour Blend. C'est un des avantages de MVVM ("Blendability").

    •  C'est quoi MVVM? Ca c'est une bonne question. Avec MVVM on met beaucoup de chose dans le meme sac. C'est une raison forte pour laquelle les gens sont confus a ce sujet. Quelques points:
    o  MVVM se marie TRES BIEN avec code-behind. Il y a des choses qu'il serait vraiment idiot de vouloir faire dans le ViewModel. Par exemple, montrer des dialogues, ou gérer des animations.
    o  On peut aussi faire du code spaghetti en MVVM. En fait, les principes de séparation (SRP, abstraction, etc.) sont tout aussi valables dans d'autres patterns, par exemple MVC.
    o  Dans ma session "Understanding the MVVM pattern" (http://www.galasoft.ch/mvvmvideo1), j'explique ça en termes que j’espère suffisamment simple à comprendre (mais bon, en anglais…)

    •  La discussion sur la taille des applications: Les plus petites applications que l'on puisse faire en ce moment (en termes de taille d'écran, mais aussi de nombre de features) sont pour le téléphone. Nous avons une bonne expérience dans ce domaine (Twitter, IMDb, SBB Mobile, History Here, etc…) et avons constaté que MVVM nous accélère le développement. Bien sûr nous connaissons la pattern "inside out" et donc c'est une manière de travailler naturelle. Mais quand même, on a pu développer l'appli Twitter en 4 semaines à 2-3 développeurs. Bon elle n'est pas parfaite (dommage que Twitter ne fasse pas de nouvelle version, c'est toujours une V1) mais au niveau de la fonctionnalité et du design, c'est une application très riche. De même avec IMDb ou SBB Mobile, toutes ces applications ont été développées en des temps courts, et avec la collaboration intensive de designers. Et toutes sont des applications utilisant MVVM.

    •  Le point sur la DAL / BOL, là je ne comprends pas bien le rapport. MVVM est une pattern pour les couches supérieures de l'application. Essayer de faire MVVM sans une couche DAL/BOL, c'est comme vouloir faire du MVC sans DAL/BOL. Il faut bien que les données viennent de quelque part ;)

    En résume, on peut travailler sans MVVM, comme on peut travailler sans Blend voire même sans Visual Studio. On peut faire du web sans MVC aussi. C'est vraiment la même problématique, et donc les mêmes réponses.

    Amicalement,
    Laurent

  • Olivier

    22/05/2011 19:41:10 | Répondre

    @Laurent: Merci de ton passage et de tes précisions.

    Quand je force le trait en parlant d'hérésie, je le sais bien, et je le dis plus loin, il suffira que j'en parle pour que d'autres disent "c'est pas faux". Et c'est ce qui ce passe (y compris les premiers commentaires hélas perdus à cause d'un problème sur le serveur).
    Bien entendu ce n'est pas le questionnement en lui-même qui est hérétique, comme toi je vois beaucoup de gens et j'entend ce qu'ils disent et beaucoup de gens s'interrogent sur le bien fondé de MVVM dans la pratique et les lourdeurs que cela implique.

    Ce qui est hérétique dans ce billet, c'est d'en parler dans un billet ! Ce questionnement sur MVVM reste dans les discussions privées mais que pour l'instant aucun blogger connu ne l'aborde. C'est en brisant ce silence que la question devient blasphématoire.

    Sinon, tu rappelles quelques évidences sur les outils, et je ne peux qu'être d'accord avec toi. Sauf peut-être sur un point : Il me semble est plus difficile de se passer de Blend pour faire du Xaml que de se passer de MVVM pour la partie code...
    Si demain on me demandait de faire une application SL ou WPF en devant choisir : tu gardes Blend ou bien tu gardes MVVM sans Blend, mon choix serait vite fait malgré tout... Je savais faire de très bons softs sous SL et WPF sans MVVM Smile

    Mais tu as raison de rappeler certains points importants de la pattern, son rôle, etc. Toutefois ce billet n'a pas pour but de dire qu'il faut éliminer MVVM, je pose en titre une question volontairement accrocheuse, pour forcer la réaction et la réflexion.

    Ce n'est donc pas tant la pattern, "dans l'idéal" qui m'intéresse ici que _l'application_ de celle-ci dans la _pratique_ et la _réalité_ des équipes informatique "standard" face à la pattern. Pas des MVP, pas les experts.

    J'ai ainsi constaté que ceux qui appliquent MVVM en viennent à faire presque disparaitre le BOL, ce qui est une erreur. Ce n'est pas la faute de MVVM, comme je le précise MVVM ne signifie pas la mort du DAL et du BOL, et tu le dis toi aussi. Mais en appelant tout cela le "Modèle" on efface un peu leur réalité et l'importance de leur rôle malgré tout.

    Tu parles aussi des applications WP7. C'est un bon exemple de "petites" applications. J'en ai écrit pas mal aussi. Et je reste convaincu que j'aurai mis le même temps sans utiliser MVVM voire moins... Non par manque de maîtrise de la pattern, juste parce si elle simplifie les choses complexes, elle complexifie, hélas, en retour beaucoup de choses simples. Ici c'est à la fois la pattern et les librairies qui sont responsables. C'est pourquoi je pose la question d'un MVVM "plus light" que light...

    Reste la "blendability". J'ai soutenu ouvertement MVVM Light (et je continue de le faire !) notamment parce que tu as fait le maximum pour que MVVM Light soit "blendable". C'est essentiel, tu as eu mille fois raison de prendre ce point essentiel en compte. Mais ici aussi, la réalité que je constate c'est que 80% (au moins) des gens qui font du Xaml n'ont pas Blend car c'est le seul élément payant ... Je ne parle pas de grosses structures pouvant payer $15000 d'abonnement prenium à MSDN, ni des MVP que nous sommes qui avons accès à cet abonnement. Mais à la grande majorité des développeurs qui n'y ont pas accès.
    Si tu regardes le forum Silvelight MSND où je suis pas mal présent (d'où en partie mon Community Award 2011), je recontre très souvent des gens qui défendent l'idée que Blend est inutile et que tout se fait à la main. Comme on rencontrait des gens affirmant que le notepad était suffisant pour faire un super site en Html...
    Donc la Blendabilité, je suis mille fois d'accord que c'est essentiel, mais dans la pratique cela n'intéresse qu'une minorité de développeur Xaml...

    Ainsi finalement le rôle du ViewModelLocator dans MVVM Light se limiterait juste à rendre cette blendability possible (notamment pour afficher des données de disign) ? N'est ce pas alors "overkilling" surtout avec ce que je viens dire sur la populatité de Blend ? Et le fait que les mécanismes de bases soient Static n'entrainent-ils pas d'autres difficultés (malgré la présence de ICleanup) ?
    Quant à la messagerie, qui marche très bien (le billet porte sur une critique de l'application de MVVM et non pas sur MVVM Light, il faut le rappeler), je ne sais pas si tu pourrais nous livrer une pattern d'utilisation claire ... Je ne pense pas... Tu te débrouilles et tu fais marcher tes softs parce que tu connais très bien la pattern et la librairie et que tu es un expert. J'ai écris un très long article de 100 pages sur MVVM Light dans lequel je présente une analyse même de ton code. Ce n'est pas moi qui l'ai écrit, mais je pense le connaître presque aussi bien que toi (je t'ai même soumis un extension pour les dialogues gérant un contexte pour le traitement de la réponse). Donc moi aussi j'arrive à me débrouiller avec tous les messages qui transitent. Nous avons l'expérience, la connaissance de la pattern, de la librairie, et nous avons un peu d'expertise... Mais cela n'est pas le cas de tous ceux qui utilisent MVVM avec ou sans MVVM Light d'ailleurs...
    Et le problème se pose justement dans les _faits_. On peut faire de longues listes des avantages de MVVM, j'en ai écrit, tu en as écrit, d'autres l'ont fait avant nous. Ce n'est pas donc pas "intellectuellement" que ça "coince", mais bien dans la "pratique".

    Pour conclure, je rappelerais que le billet est une critique de MVVM dans la pratique de son application, et non pas une critique de MVVM Light qui reste ma librairie préférée pour faire du MVVM. Et j'insisterai sur le fait que le but de ce billet est d'ouvrir une réflexion sur les simplifications qu'il faut absolument trouver pour que MVVM soit réellement plus simple à mettre en oeuvre. Sans perdre la blendability, sans perdre le couplage faible.

    Forcément ce n'est pas évident à faire. MVVM Light est un bon exemple d'implémentation minimaliste de MVVM.
    Donc j'en reviens à la question centrale : peut-on faire plus Light que Light ? ... Mon intuition me dit oui. Ma raison me dit que c'est indispensable pour les petits projets. Reste à trouver une implémentation de MVVM Light qui simplifie ce qui peut l'être sans sacrifier l'essentiel ! Caliburn s'est rendu compte de sa complexité outrancière et maintenant ils produisent Caliburn.Micro. La preuve que l'influence de MVVM "Light" a joué...
    J'espère juste avoir ouvert ici le début d'une réflexion pour une nouvelle librairie "MVVM Ultra Light" !

  • Olivier

    22/05/2011 19:55:43 | Répondre

    @paslatek: Merci de ton intervention.
    Bien entendu que le billet sonne un peu "extrêmiste". C'est une tonalité assumée, volontairement choisie pour créer le choc, en pleine mode des patterns de type MVVM (dont j'ai été l'un des premiers défenseur par de longs billets et articles, au moins en français).

    J'aime bien l'idée "pacifiste" et un peu "zen" de la "voie du milieu".
    La sagesse asiatique est intéressante... Mais en matière d'informatique je préfère me fier à des patterns, des guidelines connues, éprouvées et sûres.

    Comme tu le dis toi même, c'est au développeur de faire preuve d'intelligence et de se "débrouiller".

    C'est justement là que ça coince. Tous les développeurs n'ont pas les mêmes compétences, le même niveau d'expertise, la même intelligence, la même durée d'expérience... Cela fait beaucoup trop de variables aux conséquences énormes pour qu'on puisse s'appuyer là dessus en se disant que cela sera suffisant pour que MVVM soit "bien" apliquée...

    Et dans les faits je constate justement que ce "débrouillage" ne se passe pas très bien : code spaghetti, disparation du BOL qui se fond dans le ViewModel, DAL qui se limite à du Wcf Ria service ou un simple Web Service, messages qui se baladent dans tous les sens sans unité, sans plan rationnel ni réflexion préalable, Unit Testing tout aussi absent qu'avant MVVM, etc, etc...

    Le but d'une méthodologie est justement de permettre de gommer, tant que faire se peut, toutes les différences de compétence dans une équipe de développement. Or, dans la pratique MVVM accroit plus qu'autre chose ces différences entres les très compétents, les experts, et ceux qui sont moins doués mais qui constituent l'essentiel des développeurs dans le monde...

    Les patterns ne font pas tout, il faut de l'intelligence et de la sagesse. Mais une pattern qui, au final, repose presque uniquement sur ces points pour la réussite de sa mise en oeuvre, est, de mon avis d'expert, une mauvaise pattern...

  • Olivier

    22/05/2011 20:03:05 | Répondre

    @lummite: Merci de ton intervention.

    Je crois que plus qu'un rejet drastique ("pas de MVVM pour les petits projets") il faut plutôt essayer de voir comment on peut conserver l'essentiel de MVVM mais dans des mises en oeuvres moins lourdes.

    MVVM Light créée par Laurent est un bon exemple de cet esprit simplificateur. Il s'est concentré sur l'essentiel face à des librairies comme PRISM ou Caliburn (qui d'ailleurs en est revenu et évolue vers Caliburn.Micro...) qui étaient trop lourdes.

    Malgré l'excellent travail de Laurent qui a pris en compte blendabilité et simplicité, peut-on affirmer qu'il est allé jusqu'au bout et que MVVM Light est "parfait" ? (et je pose la question sachant que Laurent est intervenu dans ce thread) Pour ma part je pense qu'on doit pouvoir aller un cran plus loin car tout est perfectible. Laurent pratique tous les jours sa librairie et il ne voit peut-être plus les travers de MVVM aussi bien et aussi clairement que lorsqu'il a entrepris de créé MVVM Light. C'est pourquoi il me semble sain de poser la question de savoir si on peut faire plus Light que Light... Car même avec MVVM Light, l'application de MVVM laisse entrevoir beaucoup de zones d'ombre, de "débrouillardise" et de chausses-trappes.

  • Olivier

    22/05/2011 20:10:09 | Répondre

    @Thomas: Merci de ton intervention.

    A mon avis il ne faut pas voir dans MVVM uniquement une "mode" qu'il faudrait suivre parce que c'est "cool" et qui ne servirait à "rien".

    La charge de cavalerie volontairement assumée dans le ton de mon billet pourrait le laisser croire. Mais si on me lit en faisant abstraction des tournures et petites phrases qui donnent ce ton, en réalité je précise bien que MVVM propose d'excellentes choses.
    Laurent précise dans son intervention l'importance de la blendabilité qu'une librairie comme MVVM Light autorise. Il a raison. Et c'est en soi déjà un argument important en faveur de MVVM, mais s'il faut le tempérer : Blend est peu utilisé, et MVVM peut se pratiquer avec d'autres librairies qui n'ont pas toutes la même approche de la blendabilité...

    Ce que j'espère, c'est plus ouvrir la discussion sur ce que serait une librairie MVVM Ultra Light plutôt que de prôner l'abandon pur et simple de MVVM.
    Cette pattern a des choses intéressantes, c'est la mise en pratique qui ne colle pas tout à fait et la rend inutilement lourde malgré les efforts de MVVM Light ou Caliburn.Micro.
    Ne jetons pas le bébé avec l'eau du bain.
    Il faut juste réfléchir une mise en pratique encore plus Light. Et c'est cette réflexion que je souhaite ouvrir dans ce billet.

  • Thomas

    23/05/2011 10:04:06 | Répondre

    @Olivier :
    Ce n'est pas ce que je dis non plus, je pense que MVVM apporte beaucoup quand on s'en sert bien, et que c'est justifié.
    Je dis simplement qu'avant d'utiliser des outils, il faut s'assurer qu'ils apportent quelque chose d'autre que des contraintes au projet Smile

  • Sylvain

    24/05/2011 10:37:58 | Répondre

    Je suis assez d'accord avec l'article.

    On a tendance à faire beau avant de faire pratique.

    MVVM qui est à la base un outil devient à l’usure une galère. Je ne comprends par exemple pas du tout l’attachement de certain à ne pas mettre de code behind dans la vue.

    De même, le coup de la vue avec de multiple ViewModel c’est illusoire, dans la réalité une vue répond à une logique et inversement, seul le modèle peut vraiment se targuer d’être réellement indépendant.

    Pour autant, MVVM apporte des réponses intéressantes, comme les messages entre VM.
    Le coup de faire sauter le VM pour le faire entrer dans la vue n’est pas idiot, loin de là.
    Contrairement à ce que l’on se force à croire, la vue comme la VueModele de sont pas des éléments génériques réutilisables donc pourquoi s’obstiner à inventer une solution complexe pour un problème qui n’en ai pas un.

  • Sylvain

    24/05/2011 16:20:50 | Répondre

    Juste pour info j'aime assez l'approche du
    "Presentation and Navigation Models"
    tel que présenté dans UpdateControls.

  • Sylvain

    24/05/2011 16:21:52 | Répondre

    Juste pour info, j'aime assez l'approche du pattern:

    "Presentation and Navigation Models"

    Tel qu'il est présenté dans UpdateControls

  • Olivier

    24/05/2011 19:02:13 | Répondre

    @Sylvain: Je sais que Laurent, qui a fait MVVM Light, est beaucoup attaché, et avec raison, à la Blendabilité. Je le suis aussi, mais peu de gens travaillent avec Blend aujourd'hui encore.
    La VM séparée, le ViewModelLocator, tout ça est un montage inutile mais qui permet d'avoir des données de Design. C'est pratique, mais un peu dépassé.
    Il faut aussi rappeler que tous les autres framewoks comme Caliburn par exemple, de par les choix d'implémentation assez complexes, comme dans Prism, se fichent pas mal de la blendabilité. Ce qui n'empeche pas que ce sont de bonnes librairies très utilisées.

    Aujourd'hui Blend est capable de générer automatiquement des données de Design pour une classe donnée. C'est peu connu. Du Coup on peut fort bien mettre la VM (totalement adaptée à une vue dans la réalité comme tu le soulignes aussi), sans perdre les données de design : il suffit de demander à Blend d'en créer.

    MVVM complique trop les choses car beaucoup de ses avantages ne servent pas. En revanche l'esprit est bon, la gestion de message est bonne,... Il faut donc tenter de rendre l'application de la pattern plus light.

  • Sylvain

    25/05/2011 11:36:28 | Répondre

    En effet Olivier, le prix de Blend fait que des développeur "du dimanche" comme moi ne peuvent pas se permettre de dépenser 1000€ pour faire du jolie, du coup VS est la seul solution.

    J'ai longtemps utilisé MVVM light, j'ai aussi utilisé JadeMVVM pendant un moment, il y a de bonne idées.

    Mais depuis quelques mois je suis sur http://updatecontrols.net/
    Je trouve que le niveau de formalité est grandement diminué.
    Mais ce n'est pas suffisant, il manque encore quelques choses.

  • Daniel COHEN-ZARDI

    25/05/2011 16:40:36 | Répondre

    Bonjour,

    Tous ces échanges montrent surtout que la volonté de sur-découpage absolu et théorique amène des complexités insolubles.

    Au début des années 90, les méthodologues de ma société (CGI devenu IBM) développaient un modèle similaire en 6 couches, au sein de la méthode BIRD. C'était magnifique sur le papier, mais ça n'a jamais réellement marché de manière généralisée.

    La seule méthode qui marche partout et dont les vertus (bien qu'il y ait un surcoût) restent compréhensibles pour tous est le découpage en 3 couches :
    - Accès aux données (avec les requêtes qui vont bien généralement représentées par des procédures stockées)
    - Objets métiers (avec des objets sans interface utilisateur représentées par des classes d'un langage tel que C# ou Java)
    - Interface utilisateur avec la technologie qui va bien et idéalement un simple "binding" sur les objets métiers.

    Tout le reste n'est que dérive progressive de visions en couches plaquées au niveau du code des classes, et qui fait qu'on se retrouve avec des classes spécifiques ayant un nom DAL (alors qu'en .NET, la DAL c'est ADO.NET) ou un nom avec vue, alors qu'il existe des contrôles utilisateurs qui savent très bien présenter des vues qui vont bien.

    J'attends toujours qu'on me montre un projet qui ne puisse pas fonctionner avec cette architecture, et surtout, qu'on me démontre un bénéfice à complexifier au-delà de ce niveau.

    Daniel

  • Olivier

    25/05/2011 21:23:02 | Répondre

    @Sylvain: UpdateControl est une librairie qui propose des choses intéressantes, mais dans l'esprit, l'espèce de binding automatique est en réalité la même démarche que dans Caliburn.Micro par exemple. Caliburn va un peu plus loin.
    Personnellement je suis très partagé sur ces automatismes de binding. C'est pratique, mais pour les cas simples. Et je travaille rarement sur des choses simples (à prendre dans le sens où mes clients me payent justement pour les trucs compliqués, les trucs simples ils le font eux mêmes...).
    Et dans les cas complexes c'est trop "magique" je trouve. J'aime bien avoir le contrôle. Peut-être une mauvaise obsession. je ne sais pas. Je suis donc partagé, pas d'avis tranché...

    Quant à Blend, c'est très dommage de le rendre payant. Car hélas celui qui ne travaille pas sous Blend ne fait pas vraiment du xaml. Blend est le seul outil conçu pour Xaml, le designer de VS est une béquille, une aide, au mieux un truc pour une mise en place rapide d'une maquette. Comment faire du templating sous VS ? alors même que c'est un principe de développement incontournable en Xaml ? Comment faire des animations ? Comment dessiner des courbes de beziers, appliquer des transformations correctement, créer des dégradés complexes, importer des images vectorielles depuis Illustrator ou des Psd Photoshop, c'est à dire l'essentiel du travail de Design d'une appli Xaml ?

    J'ai du mal à comprendre ce choix de MS qui offre un langage graphique puissant, qui fait cadeau de VS (express), de SQL Server (express) etc, mais qui garde jalousement Blend alors même que c'est Blend qui fait la différente entre Xaml et toutes les autres plateformes concurrentes..

    Un mystère microsoftien, un de plus...

  • Olivier

    25/05/2011 21:32:12 | Répondre

    @Daniel: Tu as raison mais tu oublies que l'informatique change et évolue, et que le design compte aujourd'hui à part entière, pas comme une option. Même si beaucoup de gens n'ont pas trop compris cela, ce qui est étonnant car tout le monde se trimballe avec un IPhone et ses écrans tactiles au contenu designés et que jamais ces personnes ne reviendraient à un téléphone "standard"... Mais les évolutions d'esprit sont souvent lentes. Il faut le recul pour s'apercevoir que certaines choses sont une mode et que d'autres sont des marqueurs : il y a un avant et un après, et on ne peut rien y changer et surtout pas nier qu'on est l'après...

    Ainsi, le découpage de MVVM s'explique par la nécessité de découpler la couche graphique car elle devient un "citoyen à part entière" du logiciel.
    Dans ton découpage tu fais très attention à séparer la gestion des données des objets métiers. Par exemple ce découpage, il y a quelques années passait lui aussi pour une mode, une lubie de méthodologiste. Aujourd'hui tu l'accèptes comme une évidence.

    Peut-être te faudra-t-il encore un peu de temps pour t'apercevoir que le découplage de la couche graphique est une évidence de même ordre.

    Et là tu comprendras mieux la nécessité d'une pattern comme MVVM.

    Le problème étant que son application dans les projets de taille moyenne ou petite amène un surcout important, comme la séparation du DAL et du BOL, et que pour le moment il n'existe que deux ou trois librairies pour faire du MVVM. Aucune n'est parfaite, il faut donc continuer à travailler sur le moyen de rendre la pattern plus accessible aux petits projets. C'est là la seule vraie question.

    Le découplage de la couche graphique est aussi important que le découplage de la couche objet métier ou de la couche d'accès aux données. MVVM est en plus taillé sur mesure pour Silverlight et WPF car elle se repose sur le binding de Xaml.
    Reste à inventer des librairies plus directe, à ce que, tout simplement, VS et Blend soient construits directement autour de la pattern pour éviter la gymnastique des librairies externes !

    Tu as raison dans ta préoccupation du fonctionnel avant de faire du "beau".
    Mais tu as tort de marginaliser le "beau".
    Aujourd'hui, en tout cas pour un éditeur de logiciel, un soft doit être largement aussi beau qu'il est fonctionnel sinon il ne se vend pas...

    Cela fait désormais partie de notre métier, de gré ou de force...

  • Eric

    10/06/2011 14:11:57 | Répondre

    D'un point de vue macroscopique il me parait évident que Microsoft pousse le MVVM pour promouvoir Blend. Si personne fait du MVVM, personne ne voudra de Blend. C'est plus une histoire de sous que de modelisation,
    il me semble, finalement.

  • Olivier

    10/06/2011 19:28:35 | Répondre

    @Eric: je n'en suis pas vraiment certain. Hélas MS ne pousse pas Blend du tout, quant à WPF on sait qu'ils ont abandonné le forcing, et SL avec les annonces sur Html5 et IE9 ça a mis plutôt la pagaille...
    En réalité Blend est un produit qui s'est fait sa promo tout seul : l'essayer c'est l'adopter.
    Et puis c'est le seul designer sérieux pour faire du xaml. Comment faire du templating sérieux sous VS ? comment créer des animations sous VS ? Juste en écrivant du xaml avec le notepad sans aucun retour visuel ? Ce n'est pas raisonnable.
    Blend est un produit fantastique et incontournable, tous ceux qui l'ont utilisé ne peuvent plus s'en passer.
    Et ce qui fait de la peine justement, c'est que MS ne le pousse vraiment pas... En le laissant payant alors que le reste peut être gratuit (VS et SQL express) seuls les abonnés MSDN connaissent Blend.
    Pour faire du MVVM, MS à rajouté ce qu'il fallait à VS pour simplifier le binding.
    Reste que le générateur de données de Design, animations, templating styling, etc, etc, n'est possible qu'avec Blend. Je ne parle pas d'ajouter des dessins en courbes de Bézier, ni d'importer des layers depuis PhotoShop et Illustrator... Blend c'est un indispensable pour développer sous WPF et Silverlight.
    Et la stratégie de MS sur ce produit est vraiment mauvaise, ton commentaire en est une preuve, les gens ne savent pas ce qu'est Blend...
    Télécharge une version d'essai et essaye quelques tutos du Web, tu comprendras vite le confort incomparable qu'offre Blend ainsi que les fonctions impossiblesà faire autrement (sauf à la main mais pour moi c'est de la préhistoire travailler comme ça, comme les gars qui se vantaient de faire des sites web avec le notepad il y a 20 ans).
    Non, MS ne pousse pas Blend. Et c'est bien dommage !

  • NK54

    26/07/2011 13:45:33 | Répondre

    Alors j'ai arrété de lire les comm après la réponse d'Olivier à Laurent. (merci de son intervention Smile

    Je viens juste apporter mon expérience :

    A mes débuts silverlight et mvvm, très difficile de savoir ou situer l'accès aux données quand tout passe par des services web. Ba oui, essayez de découpez projet Model, VM, et View : on se retrouve avec 2 fichiers ServicesReferences.config, on ne sait pas si l'on doit mettre les appels aux services dans la couche model ou en view model car si c'est 100% services web tiers, on a plus rien dans le model, bref on se casse beaucoup la tête pour rien au début.

    Très très chiant à respecter le mvvm quand on à des commandes qui doivent modifier des éléments graphiques (animations etc) franchement, j'ai parfois passer des heures à faire des choses faisable en 5 minutes sans MVVM.

    Ancien utilisateur de MVVM Light (maintenant j'ai une version plus light perso avec la classe Messenger de Laurent), je n'utilisais pas le bool InDesign pour dessiner sous blend. J'utilise wcf et déjà que je perds du temps avec MVVM (ça se sent) si en plus je dois faire des données pour le mode créa design ...

    Je trouve aussi que MVVM ralonge les temps de dév pour les nouveaux qui essaye d'implémenter MVVM.

    Qui n'a jamais eu de XamlParseErrorException sous blend ou VS2k10 lors de la génération du design ? Avec une séparation des couches par projet, j'en ai eu pas mal. Du coup on se perd dans le pas à pas, les RaisePropertyChange qui pop de partout lorsque qu'on cherche d'où de quelle propriété vient l'erreur ...

    Et comme on ne voit quasiment aucun exemple d'appli MVVM avec la 10n de form, d'accès au service web pour les données (pas juste une authentification hein, ni un hello world ^^) dure d'avoir les bonnes pratiques.

    MVVM, c'est magnifique sur le papier, pour mes yeux mais pas toujours pour les temps passé en dev.

    Après c'est mon avis tiré de ma propre expérience.

    Mais je reste un amoureux de MVVM quand même ^^

  • Olivier

    01/08/2011 23:52:51 | Répondre

    @NK54: on en arrive tous là... on continue de dire que c'est beau et on fait tout pour s'en passer Smile
    MVVM est une pattern à problèmes plus qu'à solutions, mais il y a quelque chose de séduisant qui fait qu'on n'arrive pas à s'en séparer totalement.
    C'est un peu comme certaines filles... Smile

  • Ramah

    04/08/2011 17:13:10 | Répondre

    Olivier,

    Quand ton article a été publié j'ai eu un peu peur car je découdrais MVVM light et je prenais mon pied.
    Je continue toujours à le prendre mais seulement pour des tâches bien spécifiques (essentiellement des modifications sur des objets à multiples champs et pour les formulaires de saisie).


    Mais pour ce qui est de la gestion simple de certains messages(à destination de l'utilisateur, pour des évènements appelés à se répéter super fréquemment) j'utilise les bons vieux évènements.

    Pour ma part un juste milieu entre productivité, temps disponible et durée de vie de l'application permet de choisir comment s'y prendre pour la développer.

    Je me permets de faire de l'hors sujet (ne m'en veuillez pas),mais ne pas oublier qu'il y a des phases très importantes à part le développement proprement dit comme sa conception qui permet d'avoir un oeil sur la démarche à suivre. Bien évidement il faut être au courant de ce qui est faisable.

    Ma première application fut une application Windows form avec un code behind super lourd et assurément proche du spaghetti. Ceci pour tester la faisabilité du projet. Mais là elle a évolué, il est devenu facile d'y faire des modifications (une assez belle hiérarchisation) mais aussi d'y changer le design (Merci à MVVM).

    Pour résumer développer devient comme faire la cuisine. Des fois sucre et sel se retrouvent dans le même bouillon.

    Par contre des cours de design, je veux bien aussi. Car je crains.

  • NK54

    08/08/2011 16:01:25 | Répondre

    "C'est un peu comme certaines filles..." j'adore Smile

  • Tadeo

    09/09/2011 14:32:20 | Répondre

    Cinq mots : SOLID, ces cinq principes suffisent à répondre à un grand nombre de questions. Si seulement…
    De mon expérience, je pense que les MVVM, Gof Grasp, solid, etc… sont des approches et ce n’est qu’en en faisant l’expérience de chacune d’entre elles qu’on pourrait en tirer le bon et le mauvais. Seulement voilà, en SSII tout s’arrête lorsque vous avez le client et le chef devant vous qui vous demandent des comptes et des résultats.
    Je suis en partie d’accord avec ce qui a été dit dans ce billet pour ce qui concerne la mauvaise utilisation du pattern, toujours est-il que pattern = patron de conception = patron… on peut soit : suivre ses ordres ou pas !
    Alors pour ma part, et je ne suis surement pas le seul à le faire, je ne suis pas toujours ses « ordres », bien au contraire. J’essaie de prendre ce qui à mon humble avis est efficace dans chaque veille technologique que j’ai la chance de faire, d’après l’expérience généreuse de bien de personnalités compétentes qui arborent cette merveilleuse communauté, dont certains sont présents sur cette page !, (thanks by the way ! Wink )
    Egalement par expérience je dirais que si on me demandait de faire du design sans Blend, je répondrais : « ben voyons, autant faire une application console ; ça sera plus maitrisé !» j’exagère un peu… mais c’était pour appuyer le fait que je n’arrive plus à m’en passer tellement c’est un merveilleux outil qui accélère grandement les choses…
    Je finirais en félicitant l’auteur de cette page oh combien pertinente, et oh ! combien je le comprends !
    Salut à tous !
    Tad.

  • Olivier

    09/09/2011 17:29:42 | Répondre

    @tad: merci, ça fait du bien de ne pas se sentir seul Wink

  • Alexandre Trepanier

    24/10/2011 00:37:19 | Répondre

    Je suis d'accord avec les problemes que tu souleves avec MVVM.. Mais il vienne surtout du fais que les programmeurs inexpérimenté donne trop de responsabilité a leur viewmodel et de surcroit ces VM doivent communiquer ensemble..

    Selon moi, les VM doivent ne servire qu'a la presentation du model et a la presentation de commande qui ne font qu'appeler une fonction simple du model qui lui s'occupera de la commande.. J'irai meme qu'a dire qu'utiliser le view model comme facade au model est lui donner trop de responsabilité..

    Tout l'interaction et les responsabilité non UI doivent etre dans le model et non dans le viewmodel..

    Coté UI ca prends un window/dialog manager qui controle les fenetres et dialog.. et tu le mets dans ton shell ou main window. L'utilisation d'un state UI aussi est interessant pour controler les logical et visual state de l'application..

    J'aime bien utiliser des behaviors pour rajouter de la fonctionnalité UI mais il doit jamais avoir de business la dedans.

    Finalement je crois que les directives pour utiliser le MVVM patterns sont pas assez claire par ceux qui crée les framework ou qui en parle dans les blogs... puisque j'ai vu a mainte reprise des projets utilisants les viewmodels comme l'espace runtime de leur objets model.... avec un model maigre ayant peu de responsabilité en soi.

    La distribution des responsabilité est la base du clean code et on dirait que ceux qui utilise MVVM croit que par l'utilisation du pattern ta meme plus besoin de reflechir et tu fait juste tout mettre pele mele dans tes viewmodel et tu fais 200 event dans ton event aggregator a cause que tout les viewmodel veulent se parler...

    Personnelement aussi, je trouve que bcp de code dans MVVM light est generique et t'attache au framework et l'utilisation soit de convention ou d'un systeme fluent de configuration serait plus interessant pour decoupler le framework des viewmodel..

    Malgré que j'aime la simplicité de l'implémentation de celui-ci.

  • Olivier

    24/10/2011 18:43:25 | Répondre

    @Alexandre: Il y a toujours deux façons de voir les choses en matière de compréhension : soit celui qui ne comprend pas est stupide, soit celui qui enseigne est mauvais.
    On peut généraliser ça à plein de choses, et à MVVM aussi.
    De deux choses l'une, soit la majorité des développeurs est stupide, soit le pattern n'est pas assez clair...
    Moi j'opte pour la seconde chose, toi tu optes pour la première Smile

    Et j'irai même plus loin, à supposer que tous les développeurs soient stupides, alors c'est au pattern de s'adapter car c'est bien la majorité des développeurs qui est censé s'en servir.

    Maintenant on peut aussi développer un autre argument qui va dans le même sens, en tout cas qui appelle à la même conclusion :
    Dans l'industrie, n'est industriable que ce qui est réalisable par le personnel qu'on peut trouver sur le marché. C'est pourquoi en informatique comme ailleurs les très bons ont toujours du mal à trouver une boîte où ils se sentent à l'aise. Le management, les méthodes, les outils, tout ça est adapté à une majorité de gens dans la cloche de Gauss, donc moyens.
    Un patron cherchera toujours à utiliser des langages, des méthodes qui permettent de changer le salarié facilement par un autre. Ce qui n'est compris que par une "élite" fait fuir les patrons.
    Un pattern doit donc pouvoir être compris sans faille par la "masse" des développeurs, pions interchangeables entre les mains du patron.
    Et on comprends les raisons : si tu fais reposer un travail sur le fait qu'un ou deux salariés sont au-dessus du lot, tu mets en danger ta production car ils peuvent partir et il sera difficile de les échanger comme des pions.
    L'industrie, de façon rationnelle, et non idéologique, force au nivellement par la moyenne et à la constitution d'une masse de salariés interchangeables et disponibles sur le marché (et le moins cher possible puisqu'ils n'ont rien de plus que les autres...).
    Il y a là une autre raison de fuir les méthodes trop floues ou trop complexes, ainsi que les langages ou outils qui le sont.


    Et je peux dire la même chose des framework. Ils ont tous des problèmes liés à l'interprétation de MVVM, quand, pire, ils ne mélangent pas MVC ou d'autres pattern avec MVVM.

    La meilleure illustration de ce manque de clareté de MVVM en tant que pattern, c'est toi qui me la fournie avec une de tes phrases qui commencent par "Selon moi...".

    Si MVVM était aussi clair que les "vrais" pattern de type Gang Of Four, tu ne pourrais pas dire "selon moi". Soit tu comprendrais le pattern soit tu ne le comprendrais pas, mais tu ne serais pas à donner un avis personnel sur le sens du pattern.

    Ce "selon moi" résume à merveille ce que je pense de MVVM : trop de place à l'interprétation.

    Et quand un pattern est aussi flou, peut-il prétendre au statut de pattern ?

    C'est toute la question d'un autre billet d'ailleurs !

    Prism ou Caliburn sont des usines à gaz, MVVM Light est trop light. Jounce me convient parfaitement mais devient déjà complexe à bien utiliser.

    Il y a vraiment un problème avec MVVM.
    Et le plus troublant c'est que ce pattern excerce une sorte de pouvoir magique. Le pattern est flou, les frameworks mal adaptés, et pourtant on ressent la nécessité de le mettre oeuvre.
    Le résultat est souvent plus complexe qu'on l'aurait souhaité, mais on est content d'avoir implémenter son code en "respectant" MVVM. Vraiment troublant.

    C'est ce paradoxe qui fait certainement tout l'intérêt de réfléchir sur MVVM...

  • Joao Morais

    28/01/2012 10:49:40 | Répondre

    Très intéressant billet. J'en suis a mon deuxième projet avec WPF (premier en 2010, pendant 6 mois, deuxième débuté il y a 4 mois).
    Je n'ai pas autant d'expérience que cela avec WPF et MVVM, mais je suis d'accord sur la forme de ce billet: mettre en oeuvre MVVM est très lourd. Cependant, sur le fond, je pense qu'il faut 1) savoir pourquoi on utilise MVVM plutôt qu'autre chose et 2) qu'est ce que l'on essaye de faire ou d'atteindre. Je rejoins Laurent Bugnion sur le fait que l’on peut faire des applications WPF sans MVVM.
    Bien que MVVM est lourd, je continue de l'utiliser. Est-ce pour m'auto-flageller? Non. Alors, pourquoi?

    Un peu de contexte. J'ai un background assez varié (et long):
    - Fin 80’s : UI en C (‘Programmation Evénementielle')
    - 90's: UI en C (‘Programmation Evénementielle') puis C++ pour client lourd avec MVC et puis une simplification de MVC avec le Document/View proposé par Microsoft dans MFC.
    - 2000->2010:
        - Client léger, Web UI ([HTML + JavaScript] et ASP.NET)
        - Client lourd avec C# + Winforms => CAB + Model-View-Presenter
    - 2010->2011: Client lourd, C# WPF + MVVM => récemment utilisation de PRISM 4.0.

    Pour moi il n'y a pas une façon unique de développer une application (d’où la diversité des langages et des frameworks et c’est aussi pourquoi aujourd'hui JAVA n'est toujours pas devenu le langage unique). Cependant, aujourd'hui il y a de moins en moins de projet 'green-field' (partant d'une feuille blanche), on s'appuie sur l'existant et les ressources disponibles. Je conçois et développe des solutions autour de .NET, donc je vais déjà orienter et réduire mes choix lorsque je propose des solutions à mes clients. Ces derniers recherchent une solution qui leur apporte des valeurs ajoutées:
    - d'un point de vue fonctionnelle (le Quoi?)
    - d'un point de vue date de livraison (le quand ?)
    - d'un point de vue maintenance (le qui? et comment?)
    - d'un point de vue coût (le combien ca va me couter?)
    - ...

    (Il n'y a pas d'analogie parfaite, cependant renforcer le trait avec quelque chose de quotidien permet de faire passer un message plus simplement ...)
    Pour moi, commencer à développer une application WPF (ou SilverLight) avec MVVM (Model-View-ViewModel), MVC (Model-View-Controler) ou MVP (Model-View-Presenter) c'est comme débuter sa vie de conducteur d'automobile avec un camion de 38T (38 Tonnes): est-ce que pour aller de mon domicile à mon travail j'ai besoin de conduire un 38T?
    - Non, si je suis un développeur .NET avec mon ordinateur portable je n'ai pas besoin de ça.
    - Oui, si mon travail consiste à livrer plusieurs tonnes de marchandises.

    Lorsque MVC fut introduit au milieu des années 1970 avec la plateforme de développement Small Talk, c'était une avancée (cela allait de paire avec la 'programmation événementielle'). Cependant, dans les 1990, les gens qui devaient passer d'une programmation où la navigation UI etait basée principalement sur des écrans séquentiels (DOS – 70 a 80% des dev dans les entreprises) à Windows ('programmation événementielle' des fenêtres) c'était aussi très compliqué. MVC était le pattern et buz de l'époque. Il y avait des développeurs qui arrivaient à utiliser ce pattern correctement, mais c'était une poignée de gens.

    Début 2000, les méthodologies agiles et "tests unitaires" ont commencé à se répandre. Il fallait automatiser le plus que possible les tests, et cela était valable pour les UI (clients lourds ou léger, i.e. le Web).

    En 2004, Martin Fowler a publié un article sur 'Presentation Model', qui dans le CAB (Composite Application Block) de Microsoft est dénommé MVP (Model-View-Presenter). Ce fut là une avancée dans le développement des UI, car dans mon cas, depuis 2000, je dois mettre en place des tests automatisés. Or tester la logique qui était souvent incorporée ou référençait des éléments graphiques était quasi impossible. Il fallait automatiser les tests via l'UI. Or à ce jour, c'est toujours un problème dès lors qu'il y a des changements de comportements ou des éléments graphiques (j'espère que cela viendra) et cela coute très cher (les applications sur lesquelles j'ai travaillées avaient plusieurs dizaines d'écrans. Certaines pages Web avaient plus de 100 liens - c'est la vie !).

    En 2005, Microsoft dévoile plusieurs technologies Avalon (aka WPF), Indigo (aka WCF), Windows Workflow ainsi que XAML, un markup langage pour les applications (WPF et Windows Workflow l'utilisent abondamment). John Grossman dévoile cette année là aussi un pattern, le MVVM qui va s'appuyer sur de nouveaux concepts de WPF : Data binding, les templates, les commandes et les behaviours.

    Un outil fait aussi son apparition, Blend Expression. Il est fait pour les Designers, mais ces derniers ne comprennent pas bien le ‘plus’ de cet outil: ils ont déjà PhotoShop, Illustrator et Adobe Premiere. Pourquoi Blend? c'est un superbe outil qui permet d'intégrer le code, le XAML, les documents multimédias. Cela va de paire avec un nouveau processus de développement des applications - pour avoir travaillé dans le multimédias, i.e. avec des graphistes, des illustrateurs, des artistes sonores, ... l'évolution des applications va vers du 'plus beau'. L'I-Phone en est l'icone parfaite - mais j'adore bien plus mon Windows Phone ;) .


    Si l'on regarde bien:
    - MVC apportait un ‘plus’ lors des UI événementiels - aujourd'hui les plateformes et langages de développement apportent les événements nativement. La plupart des développeurs ont grandi et savent développer ce type d'interface graphique.
    - MVP et MVVM sont arrivés après que des méthodologies Agiles (XP, SCRUM, ...) ont commencé à se mettre en place et les tests (unitaires) automatisés devenaient populaires.
    - MVVM est arrivé après que certains projets utilisent des sources multimédias (images, sons, vidéos, 3D, ..) et où des designers et développeurs doivent travailler ensembles.

    MVC, MVP et MVVM sont des patterns composites, i.e. ils sont basés et composés d'autres patterns. C'est une des sources de leur complexité. Une autre source de leur complexité est que si l'on ne comprend pas (et je suis d'accord avec toi Olivier, il faut un pattern clair, mais il faut aussi savoir et comprendre l'origine d'un pattern) pourquoi le pattern a été créé, quel(s) problème(s) il est censé résoudre, alors il faut peut-être utiliser autre chose - ce qui n'empêche pas d'étudier le pattern, de le pratiquer à petite échelle pour se familiariser avec.

    A la question ‘Pourquoi j’utilise encore MVVM’ ? Voici ma réponse :
    - Il apporte le découplage nécessaire entre :
        1) Les données (contenues dans le Model) ;
        2) La gestion de l’état visuel et des comportements (contenus dans le ViewModel) ;
        3) Et les éléments purement graphiques dans l’application (contenus au niveau des vues).
    - Les tests sont automatisés sur mes « Models » et « ViewModels ». Ce qui manque à tester c’est les liens (le  ‘wiring’) entre mes « Views » et mes « ViewModels ».
    - L’automatisation des tests nous permet de livrer une application modifiée sur des cycles cours : je parle de patchs en Production toutes les semaines et des livraisons majeures tous les mois.
    - Cela permet de nous rassurer et le client aussi quant à la qualité du logiciel qui va être livré.
    - Les designers et développeurs peuvent travailler ensembles. Il est vrai que c’est une question de moyens et d’image. Sur des applications pour le public (Site Web ou applications grand public), on retrouve plus souvent les designers. Pour une application interne à l’entreprise, c’est très très rare – je te rejoins sur ce point.

    J'ai imprimé ce billet avec les commentaires, bien entendu, la taille de la police peut varier, mais il s'est étendu sur 30 pages. De quoi faire réfléchir. En tout cas merci pour ce billet.

    En conclusion (sinon mon commentaire sera plus long que ton billet ;) ), je dis qu'il faut choisir ces outils/patterns en fonction du but recherché. Mais encore faut-il savoir que l'on ne connait pas tout (ce qui réduit nos choix), et qu'une partie de la connaissance vient aussi par la pratique (et les erreurs sont là pour nous aider ;) ).

  • Olivier

    01/02/2012 11:39:14 | Répondre

    @Joao : merci pour ce long commentaire !
    Le but était ici de faire réagir les lecteurs pour que s'établisse un dialogue permettant de mieux cerner le "pourquoi" de l'utilisation de MVVM.
    Ton expérience enrichit le débat.

  • Mabyre

    19/04/2012 12:23:31 | Répondre

    Franchement, cela me fait bien plaisir de vous lire. J'avais un doute me voilà rassuré, je ne suis pas le seul à me poser des questions sur MVVM. Développeur ASP.NET entre 2006 et 2009 je suis passé par Silverlight puis avec WPF, je pensais que je pourrais développer aussi pour le web avec XBAP …

    Ayant été affilié au msdn comme jeune entreprise, je cherche à ne pas payer les 3500$ qui me sont demandés aujourd'hui et donc je n'ai pas accès à Blend et n'ai pu le voir à l'oeuvre que pendant une session de formation d'une demi journée !

    Je vois tous les jeunes développeurs se jeter sur MVVM pensant qu'ils vont pouvoir tout faire facilement et là, c'est la catastrophe. Ils se heurtent au problème dont parlais Olivier de messages et communication entre les ViewModels. Il s'en suit des discussions interminables.

    Personnellement, je vais orienter mes recherches sur Prism car finalement autant aller jusqu'au bout de la démarche. Mais je vois que certains comme Karl Shifflet créé des classes comme l'EventAggregatorResolver pour " pallier au manque de MVVM avec Prims ".

    En conclusion : je suis un peu déçu (lol)

  • Olivier

    20/04/2012 14:56:18 | Répondre

    @mabyre: j'en ai déja parlé: peut on donner le statut de "pattern " à MVVM comme on le fait pout d'autres ? Je ne le pense pas. Il y a quelque chose d'inachevé dans MVVM, la mise en oeuvre... trop d'interprétations possibles donc trop d'erreurs possibles.
    MVVM est une methode interressante mais elle demande en realite une planification qui impose d'avoir une bonne maitrise de la lib utilisee et de l'experience...ce qui est paradoxal pour une pattern qui permet par essence de tirer profit de l'experience de l'auteur...
    prism ? C'est une lib riche mais complexe... la ou elle semblera repondre aux questions...elle en soulevera d'autres plus complexes ! A mon avis mieux vaut garder mvvm light ou jounce et s'y former, arreter des strategies et s'y tenir...

  • Daniel B

    12/06/2012 16:21:12 | Répondre

    Wow quel bonheur de lire cet article et de voir que je ne suis pas fou (du moins pas tant que ça).  Merci et bravo


  • serrr@yahoo.fr

    25/12/2013 15:28:00 | Répondre

    Merci de partager vos infos. J'apprécie vraiment vos efforts. Merci une fois encore une fois.

Pingbacks and trackbacks (5)+

Ajouter un commentaire