Dot.Blog

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

WPF / Silverlight : MVVM est-elle une vraie pattern ?

[new:30/08/2011]Il y a déjà quelques temps j’ouvrais le débat “Faut-il bruler MVVM ?” où j’expliquais qu’il y a peut-être matière à réflexion autour d’une réforme de cette pattern qui ne tient pas toutes ses promesses. Aujourd’hui je vais un cran plus loin en affirmant que MVVM n’est pas une pattern.

Masochisme ?

D’abord, vous risquez de penser que je suis masochiste. C’est vrai, pourquoi m’acharner à utiliser une pattern que je trouve si imparfaite ? Pourquoi ne pas lâcher l’affaire et passer à autre chose ? Il y a tellement de pattern du même type...

Alors je dois réaffirmer que MVVM contient de nombreuses bonnes idées qui sont des avancées difficiles à renier, que MVVM est récente et conçue dans l’esprit XAML et que revenir en arrière en l’abandonnant totalement serait idiot.

Quant à utiliser “autre chose”, je ne connais rien du même type qui soit parfait. MVP (créée en 96 par Mike Potel pour C++ et IBM Java), VP et toutes leurs cousines reposent sur des principes proches mais pour d’anciens systèmes et, à l’usage, s’avèrent aussi poser des problèmes. Je ne parle même pas de patterns comme MVC (issue de Smalltak dans les années 70 !) qui finissent divisées en sous-branches incompréhensibles (MVC a été “revue” par Martin Fowler et dérivée en “Supervising Controler” et en “Passive View”, patterns bien difficiles à différencier).

Dans le précédent billet que je cite plus haut, je souhaitais ouvrir un débat, une discussion large sur les faiblesses de MVVM dans le but d’initier une “réforme”, une évolution de la pattern. C’est toujours dans ce même esprit que je m’exprime aujourd’hui.

MVVM est “la bonne idée”, en tout cas le bon noyau fondateur, moderne, mais il lui manque des choses.

Qu’est-ce qu’une pattern ?

Une “design pattern” ou “patron de conception” est un concept de génie logiciel hérité de l’architecture. C’est en effet un architecte viennois (mais ayant vécu en Angleterre ce qu’on oublie souvent), Christopher Alexander qui dans les années 70 eut l’idée d’écrire un livre qui se composait de “recettes” applicables en architecture. Chaque pattern étant présentée sous une forme bien précise : son nom, le problème à traiter, la solution détaillée (éléments en jeu, leurs relations et responsabilités) et les conséquences... De la poigné de porte à une ville entière, Alexander définissait ainsi un catalogue de solution éprouvées (“A Pattern Language : Towns, Buildings, Construction”).

En informatique l’idée sera reprise en 1995 par le célèbre “Gang of Four” ou GoF (Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides) dans leur livre “Design Patterns – Elements of Reusable Object-Oriented Software”.

Une design pattern est un formalisme. On trouve d’autres segmentations que celles d’Alexander comme “Intention, Motivation, Solution, Conséquences”. Mais l’idée reste la même, le formalisme de base reste cohérent.

Chaque “design pattern” décrit ainsi un problème spécifique mais qui se rencontre couramment dans l’écriture d’un logiciel. Après avoir décrit le problème et son contexte, les auteurs décrivent une solution fiable aux conséquences connues (par exemple sur la vitesse d’exécution, la consommation mémoire). Le but étant de décrire chaque problème et sa solution de telle façon “que l’on puisse réutilisation cette solution des millions de fois, sans jamais le faire deux fois de la même manière”.

Les design patterns sont des condensés de savoir et d’expérience. Le GoF était constitué d’experts, des gens qui écrivaient de vrais logiciels et qui avaient atteint une maitrise certaine de leur art. Ce n’était pas des théoriciens fous, des méthodologistes universitaires enfermés dans leur tour d’ivoire.

Les designs patterns sont le fruit d’une réflexion poussée autour d’une expérience. Il ne s’agit pas surtout de “ballons d’essai théorique” lancés en l’air pour '”voir ce que cela va donner” ! Au lieu de partir d’une théorie, d’une méthode de chercheur et d’essayer d’en trouver des applications pratiques, avec les design patterns ont part de l’expérience, enrichie par plusieurs vécus différents, et on tente de formaliser ce savoir accumulé. C’est totalement différent. Dans un cas on est dans l’essayisme pur et dangereux, dans le second on avance en terre connue et balisée par la pattern.

Je dirais même que les design pattern, que ce sont ensuite réappropriés les théoriciens et autres méthodologistes, sont en quelque sorte la revanche des ingénieurs sur ces derniers. Les design pattern prouvent que dans notre métier, comme en architecture, il est bien préférable, pour créer de bons logiciels, de formaliser son expérience que de vouloir imposer des théories non éprouvées par les faits issue de chercheurs qui jamais n’ont écrits le moindre logiciel...

Donc voici ce qu’est une design pattern : un sirop, un extrait, un élixir d’expérience formalisée aux conséquences mesurées, assumées, et commentées.

Les conséquences font la pattern

En fait, on pourrait en arriver à définir les design patterns par la fin : c’est bien plus la mise en évidence claire des conséquences positives et négatives de leur application qui en fait des patterns réutilisables que l’exposé de la solution au problème !

Des solutions aux problèmes, interrogez 100 développeurs et vous obtiendrez 100 réponses différences.

Nous ne sommes pas à la recherche de solutions.

Nous sommes à la recherche d’expérience !

Et ce qui caractérise une design pattern est bien la partie “conséquence” de sa présentation. C’est ce qui prouve qu’elle est issue de l’expérience et qu’on peut prévoir à quoi s’attendre en l’appliquant.

Sans cela, une design pattern n’est qu’une solution parmi des centaines. Pire, qu’une “bonne idée” qu’il reste à tester avant d’en faire une pattern, donc dangereuse à utiliser...

C’est l’expérience véhiculée par les conséquences clairement énoncées qui font toute la valeur d’une design pattern.

Bien entendu, l’élégance de la solution proposée compte aussi. Mais sans le retour d’expérience qui s’exprime par la connaissance des conséquence de son utilisation, cela resterait qu’une solution de plus. Des solutions élégantes il est toujours possible d’en trouver plusieurs pour un même problème. Mais qui soient validées par l’expérience de leur mise en pratique, il y en a moins, et ce sont des design patterns dès que tout cela est formalisé sérieusement.

MVVM peut-elle être considérée comme une design pattern ?

Non.

Elle ne se présent pas comme une design pattern du GoF par exemple. Et notamment il lui manque l’essentiel : les conséquences connues et prévisibles de son application.

MVVM est juste une entrée de blog... Une bonne idée présentée par John Gossman le 8 octobre 2005 dans l’un de ses billet intitulé “Tales Form The Smart Client”.

MVVM ouvre des voies, assène des lois, fait la publicité de tout ce qu’elle apporte de bon, mais jamais MVVM n’explique les conséquences de son utilisation. Jamais elle ne permet d’avoir cette assurance qu’une vraie design pattern apporte.

MVVM est une bonne idée lancée en l’air, mais elle n’est pas présentée comme doit l’être une design pattern, elle n’en suit pas le formalisme et elle ne se base pas sur une longue expérience qu’on tente de formaliser. Elle née presque en même temps que les techniques qu’elle utilise, comme une guideline. Mais pas comme une pattern riche d’un retour d’expérience.

De fait, MVVM c’est juste une “bonne idée” qui est lancée en l’air. Chacun essayant de l’appliquer à sa façon. Avec plus ou moins de bonheur.

Prism, Caliburn, MVVM Light, Jounce, et bien d’autres toolkits ou frameworks tournent plus ou moins directement autour de l’idée de MVVM. Aucun ne règle tous les problèmes et souvent en pose de nouveaux qui restent sans solution.

Appliquer MVVM oblige à choisir un toolkit, et avec lui ses inévitables faiblesses. Beaucoup de ces toolkits sont d’ailleurs l’œuvre d’un seul homme (MVVM Light, Jounce, Caliburn...) qui, aussi compétent soit-il, fabrique son toolkit personnel en fonction de sa propre expérience puis tente, en fonction des retours (les siens et de ses utilisateurs) de combler les manques. C’est ainsi que le concepteur de Caliburn a décidé de tout reprendre à zéro et de concevoir Caliburn.Micro, non pas comme une version minimaliste mais bien en remplacement de Caliburn. On avance par petit sauts, on bricole chacun dans son coin, on recommence. C’est beau, cela s’appelle s’expérience et c’est justement ce qui manque à MVVM pour être une vraie pattern...

Mais quand je prend une design pattern du GoF, je n’ai pas tous ces aléas... J’ai du solide, du prévisible, toujours valable presque 20 ans après la sortie de leur livre ! C’est ça une design pattern : quelque chose de solide et de fixe, un moule sur lequel on peut compter, tout en ayant la liberté de réaliser autant de versions différentes selon les besoins. Mais jamais on ne remet en question le moule lui-même, la design pattern.

Je ne voudrais pas donner l’impression de “sacraliser” les design patterns du GoF. Rien n’est sacré, pas même le sacré. Je suis un libre penseur et aucune loi, ni divine ni humaine ne s’impose à moi sans que je m’octroie le droit légitime et absolu de l’examiner, de la soupeser, d’en vérifier la validité.

Les design patterns du GoF ne sont donc pas sacrées. Elles sont juste bien faites et je peux compter sur elles !

MVVM n’est pas de cette nature.

MVVM est juste une “bonne idée”, ou plutôt une liste de “bonnes idées”. Une direction intéressante à suivre, une réflexion empreinte de bon sens. Mais comme toutes les “bonnes idées”, il ne s’agit pas d’un “package complet” utilisable “tel quel”, juste un guide qui doit forcer à raisonner, à s’interroger.

MVVM est “l’idée d’une pattern” qu’il reste à créer.

Quelles conséquences à ce changement de statut ?

En remettant MVVM à sa place, en la délogeant du piédestal du statut de design pattern, on ne tue pas les bonnes idées qu’elle véhicule. Dans ce billet-ci non plus je ne brulerais pas MVVM !

En revanche je la remets à sa place : de bonnes idées qui nécessitent encore beaucoup de travail et d’expérience avant d’atteindre le niveau de ce que doit être une vraie design pattern.

C’est une invitation au travail, à la réflexion. Ce n’est pas un discours nihiliste, d’aucune manière.

MVVM mérite notre attention. Mais on ne peut la considérer comme une design pattern “finie”. Juste “l’idée de ce que pourrait être une pattern de ce type”.

Elle pose trop de questions sans réponses, elle laisse le champ libre à trop d’interprétations personnelles, à trop de frameworks ou de toolkits radicalement différents qui chacun ne répond que partiellement aux attentes.

Prenons un simple exemple : MVVM a été pensé par un fondateur de WPF. MVVM fait donc usage du data binding et de tout ce qui caractérisait à l’époque WPF. Null doute que si MVVM avait été énoncé hier, elle prendrait en compte la blendabilité. Sur l’ensemble des toolkits cités dans ce billet, seul MVVM Light prend ce point essentiel en compte (avec Jounce mais d’une autre façon).

Mais pour y arriver MVVM Light utilise un locator avec des propriétés statiques. Impossible d’utiliser MVVM Light et sa blendabilité avec MEF par exemple...

Est-ce la faute de MVVM Light de ne pas offrir de solution à ce problème, est-ce la faute de MEF de ne rien prévoir pour la blendabilité ? Ou bien est-ce la faute à la “pattern” MVVM ne n’être pas “finie”, pas complète, de manquer de recul, de n’être pas capable de suivre les évolutions du monde qui l’a vu naitre ?

Si on considère que MVVM n’est qu’une bonne idée, qu’une voie à suivre et à étudier, alors on comprends mieux la situation : chacun tâtonne, essaye de donner “son” interprétation de ce qu’il comprend de l’essence de MVVM, mettant l’accent sur ce qui le gêne au quotidien, ignorant superbement les autres problèmes posés par l’application de cette “pattern”.

Il reste beaucoup de travail avant de faire de MVMV une design pattern.

Les conséquences de cet état fait sont évidentes : Appliquer MVVM comme une pattern est une erreur. Croire que tel ou tel “écart” en “viole” les lois est stupide car on ne viole pas une “bonne idée”, on ne viole qu’une pattern. Une bonne idée, on “l’adapte”, grâce à l’expérience. Cela fait une grande nuance.

Et alors ?

Bonne question... Je n’ai pas de solution à vous offrir, et ce n’était pas mon propos. Je voulais seulement rappeler que MVVM n’est que le début du chemin qui mènera à une design pattern, mais qu’en l’état ce n’en est pas une. Avec toutes les conséquences que cela entraine.

  • La fin des discours parfois extrémistes sur tel ou tel “viol” de la pattern.
  • La fin du rêve qu’un '”absolu” serait atteint en appliquant la “pattern”.
  • La fin de l’illusion qu’appliquer MVVM répond à tous les problèmes qu’elle soulève.
  • Le début d’une nouvelle histoire qui reste à écrire.
  • Le début d’une nouvelle impulsion, pour se mettre au travail et trouver comment faire de cette bonne idée une vraie pattern...

Conclusion

Dans notre métier secoué régulièrement par les modes et les sigles étranges qui font passer pour des idiots ceux qui n’en connaissent pas la signification, MVVM a su créer son buzz. On pourrait dire qu’il n’y a pas de fumée sans feu. C’est souvent vrai (pas toujours), et si MVVM connait un certain succès c’est bien qu’elle véhicule de bonnes idées, séduisantes.

Mais MVVM ne serait rien sans les toolkits ou frameworks qui en offre une vision personnelle. C’est grâce à ces outils que MVVM gagne en expérience ce qui lui permettra, un jour peut-être, d’atteindre le statut de “design pattern”.

Il est ainsi hors de question de jeter la pierre à tel ou tel autre framework. Il est tout autant hors de propos de les renier et d’oublier les voies que tracent MVVM.

Il faut continuer à mettre œuvre MVVM, il faut que chacun exploite plusieurs toolkits et frameworks pour en comprendre les forces et les faiblesses.

Il n’y a que comme cela, par l’accumulation de l’expérience, qu’un jour, l’un d’entre nous sera capable de formaliser réellement MVVM, d’en faire une vraie design pattern aux conséquences maitrisées et sur laquelle pourront être bâtis des frameworks solides et non pas parcellaires.

Rendons une fois encore hommage à ceux qui produisent des frameworks ou des toolkits MVVM, ils font avancer les choses. Rendons un hommage tout aussi appuyé à ceux qui ont le courage de s’en servir pour créer de vraies applications qui dépassent le stade de la démonstration. Leur prise de risque est énorme et leur expérience accumulée est notre espoir de fonder une vraie pattern sur MVVM. Rendons peut-être aussi, et très humblement, un hommage à ceux qui réfléchissent à MVVM et qui prennent parfois beaucoup de temps à l’expliquer à la communauté pour faire avancer les choses...

D’ailleurs, après le gros article sur MEF (qui sera publié d’ici quelques jours), je vais m’attaquer à une présentation en détail de Jounce que je trouve très séduisant.

Autant de raisons de....

Stay Tuned !

Faites des heureux, PARTAGEZ l'article !

Commentaires (11) -

  • Sébastien

    07/08/2011 22:41:21 | Répondre

    Excellente réflexion et en grande partie en accord avec cet article. Pour ma part MVVM ne doit pas être vu comme une pattern dans le sens il n'y a jamais de façon unique de résoudre un problème et où chacun pourra proposer sa propre solution.

    Mais c'est peut-être en créant ce genre de réflexion que MVVM pourra devenir un jour, une vraie pattern.

    Sébastien.

  • Simon Mourier

    08/08/2011 09:00:08 | Répondre

    Un article qui a le mérite de ne pas prendre le même train que tout le monde Smile

    PS: pourquoi féminiser les pattern? La traduction la plus proche c'est "motif". Si on se réfère à wikipédia, c'est plutôt "un pattern" en français.

  • Olivier

    08/08/2011 18:31:55 | Répondre

    @boLT: oui, je connais ce billet mais c'est une bonne idée que de l'avoir en référence ici. Merci du lien.
    Chacun fait sa propre tambouille, c'est une bonne illustration de ce que je dis ici.

  • Olivier

    08/08/2011 18:39:35 | Répondre

    @Simon: Bonne question pour le genre des patterns.. Une vieille habitude qui doit venir de quelqu'un d'autre au début de l'utilisation du terme !
    De toute façon c'est un mot anglais qui n'a pas de genre,le neutre n'existe pas en français, en revanche les anglo-saxons ont de plus en plus tendance à utiliser le féminin dans les situations mixtes. Par exemple en utilisant uniquement "she" quand on ne sait pas si c'est "he ou she". En utilisant aussi "she" pour un bébé, mâle ou femelle, etc.
    Je dirais alors que dire "la" pattern se rapproche plus de la façon de féminiser les neutres ou les indécis en anglais. Si j'utilise un mot français comme "patron", il garde son genre, mais le mot français n'est pas le mot anglais je ne peux pas porter son genre sur le mot anglais. Cette logique là n'est pas mieux fondée que celle que j'utilise. Une question de choix donc. Et puis de sonnorité. "Une Design Pattern" m'est plus agréable à l'oreille que "un Design Pattern". Ici encore question de goût Smile
    Si l'âme du regretté Me Capello vient un jour souffler sur ce blog, qu'il nous fasse un signe !

  • Beja

    09/08/2011 00:58:01 | Répondre

    A propos du genre de Design Pattern, il est de rigeur de prendre le genre de l'équivalent français.

    Ainsi on dit une PlayStation, car c'est UNE station de jeu. Alors qu'on dit un gamecube, car il s'agit d'UN cube de jeu (et ce, peu importe la volonté de son concepteur qui a voulu imposé le féminin pour coller à son concurrent, c'est le masculin qui a toujours prédominé).

    Et le design pattern, dont tu donnes toi-même l'équivalent français, est UN patron de conception. C'est bien la première fois où j'entend ça au féminin...

  • Olivier

    09/08/2011 19:32:13 | Répondre

    @Beja: Ton explication est parfaitement logique.

    Et c'est le même rasionnement qui explique le fait que j'utilise le féminin !

    En tant que compositeur et musicien, bien avant d'être informaticien, les patterns (des boîtes à ryhtme par exemple) est un mot que j'ai entendu toujours utilisé au féminin certainement car l'équivalent français le plus proche est "une boucle" (qui se traduit par loop en anglais sans avoir le même sens que pattern qui ici fait plutôt référence au "dessin", à la pattern, que forme les points allumés ou éteints sur les lignes des instruments).
    De cette formation musicale qui date de mon enfance (et de mon adolescence pour mon premier synthé modulaire avec sequencer), j'ai certainement conservé cette habitude de féminiser "pattern"...
    Du coup, le masculin m'arrache les oreilles.

    Pour trancher je dirais que s'agissant d'un mot étranger non traduit alors qu'il existe des traductions officielles en français, je pense en réalité pouvoir prendre les libertés que je veux.
    Les vrais tatillons diront "patrons de conception" et n'utiliseront pas "design pattern" de toute façon...

    Alors n'être tatillon qu'à moitié est-ce finalement plus légitime que ma fantaisie qui a aussi sa logique ? ....

    (Bien qu'en informatique, pour être juste, le masculin semble le mieux approprié, en vertu de la même logique).

  • Beja

    09/08/2011 20:15:09 | Répondre

    Bien sur chacun est libre de faire ce qu'on veut, c'est juste que c'est plus facile à lire avec la forme communément utilisé, dont tu vois toi-même la justesse Smile

    Enfin ce qu'un détail de langage, tout comme ces états d'âmes sur la valeur lexical à associé au "nouveau" jouet pondu par un papa très content de son nouveau outil.

    Je trouve tes articles plus "techniques" tel que celui qui compare de manière factuelle les différentes approchent du MVVM par quelques pattern bien interessant que ce genre d'appel au troll, qui, tu l'as vu, peut partir d'un mot ("une") pour en faire 50 (mon commentaire) puis 500 (ta réponse) pour au final arriver à un campement de position ;)

    Et encore, dans ce cas précis on a la chance d'avoir quand même une logique sous jascente simple, dans le cas du MVVM, dans 1000 ans on sera toujours au même point imo ^^

  • Olivier

    10/08/2011 18:29:21 | Répondre

    @Beja: Il ne faut pas avoir peur du troll. On peut ne pas être d'accord sur un point, un détail futile ici, et défendre sa vision des choses sans pour autant perdre le sourire Smile

    Tiens, je vais essayer la prochaine fois de dire "un design pattern", rien que pour te faire plaisir, et te prouver qu'échanger des points de vues différents peut faire changer les choses sans pour autant que cela ne soit un troll. Promis je vais essayer ! Smile

  • Paslatek

    11/08/2011 12:23:38 | Répondre

    Sujet interressant.
    Je te rejoins sur pas mal de point et je reviens à la charge avec ma "voie du milieu". Juste ma façon à moi de dire un peu la même chose que toi concernant les "extremistes" de MVVM qui font tout pour ne pas "violer" une soi disante rêgle du pattern (tu noteras le masculin ;) ), quitte à développer des milliers de lignes de codes au final pour permettre un databinding hasardeux sur un controle qui ne le permettait pas à la base....
    Bref,
    Ceci dit j'ai du mal à voir la frontière entre ce que tu apelles "conséquences" du pattern et "retours d'experiences" qu'ils soient négatifs ou positifs. Aujourd'hui on connait une partie des retours positifs du MVVM ainsi que les negatifs (par exemple la difficulté sur la blendabilité). N'est-ce pas déjà des conséquences ?

  • Olivier

    15/08/2011 03:52:45 | Répondre

    @Paslatek:
    La "voie du milieu" n'est pas vraiment formalisée comme "pattern" ça pose donc aussi problème Smile

    La différence que je fais entre "conséquences" et "retour d'expérience" se joue dans le formalisme.
    Des retours d'expérience sur MVVM, on commence a en avoir. Je continue à penser que le problème vient plus du changement d'approche et du choix des toolkits que "du" (aie! mes oreilles! ;) ) pattern lui-même.
    Les difficultés que je vois dans l'application de MVVM sont principalement liées au fait que les développeurs ont beaucoup de mal à raisonner telle que le pattern le voudrait et que certains toolkits sont soit trop simples (MVVM Light par exemple), soit trop complexes (Pris, Caliburn).
    Il n'en reste pas moins vrai que le pattern MVVM n'est pas à mes yeux un vrai pattern car il n'en suit tout simplement pas le formalisme !
    Quelle différence entre une guideline, un bon conseil, une bonne idée, ou un pattern ? C'est qu'un pattern suit un formalisme strict.
    Et ce formalisme oblige à une certaine présentation, dont celle des "conséquences" de l'adoption du pattern.
    Il ne s'agit pas seulement de "retours d'expérience" de pierre paul ou jacques, il s'agit d'un texte clair rangé sous le titre de "conséquences" et qu'on peut lire facilement dans la présentation du pattern avant de s'en servir. Bien entendu ce paragraphe est issu de l'expérience. Mais une expérience formalisée et qui doit être signée de la main de personnes qui "font autorité" comme le GoF par exemple.
    MVVM, ce n'est qu'une entrée de blog... Comme on discute là, entre nous. Rien de plus. Ce n'est pas un pattern qui a fait l'objet d'une publication officielle validée par des gens reconnus dans le monde de la méthodologie. Et il manque à MVVM, non pas le retour d'expérience des développeurs, mais la formalisation de cette expérience signée par une main connue sous le titre "conséquences" dans un document respectant le formalisme de publication d'un pattern.
    Dis comme ça, ça fait un peu tatillons. Mais la différence est énorme.
    Finalement nos expériences valent bien celles d'un membre du GoF ! Oui, c'est sur. A nous tous le retour d'expérience a une grande valeur malgré tout. Mais là n'est pas vraiment la question. Le problème c'est tout simplement que MVVM n'a jamais été formulé comme un pattern, et qu'aucune publication sérieuse n'a présenté ce pattern comme tous les patterns le sont.
    Celui qui veut aborder MVVM ne peut pas prendre connaissance de la "fiche de MVVM" comme il peut le faire pour le pattern "abstract factory" ou "decorator" par exemple.
    Le "retour d'expérience" tel qu'on l'évoque ici c'est une sorte de "bouche à oreille". Les "conséquences" dont je parle, c'est un document validé par une autorité consultable avant de servir du pattern.
    En réalité il manque à MVVM un vrai formalisme, une vraie publication sérieuse, et la validation de personnes faisant autorité. Or, ce n'est qu'un billet sur un blog. D'un type compétent et intelligent, mais ça reste une entrée de blog. C'est là le principal problème. Chacun ensuite essayant de créer son petit (ou gros) framework en "interprétant" le sens de ce billet ...
    Par exemple en ce moment je suis en train de boucler un article sur Jounce, ce qui me force aussi à regarder de plus près ce toolkit qui me semblait prometteur. L'auteur s'est "inspiré" de Prism et Caliburn pour en faire quelque chose de plus "light". Et Jounce c'est très bien. C'est en quelque sorte l'amélioration que j'attends du retour d'expérience. Ce n'est pas parfait, et j'espère que d'autres tenteront aussi synthétiser ce qui se fait autour de MVVM pour proposer des toolkits de plus en plus proche du besoin, léger mais puissants. Mais d'un autre côté cela prouve ce que je dis : le pattern en lui-même n'en est pas un, juste une série de bonnes idées qui peuvent être "interprétées" au bon vouloir de chacun. Les toolkits sont soit bons, excellents ou mauvais, alors que tous "respectent" MVVM ce qui prouve que "suivre MVVM" n'est pas suffisant, qu'il manque un peu d'étoffe au costume pour en faire un vrai pattern indiscutable.
    Mais je suis content de voir des choses comme Jounce, l'article paraitra d'ici une semaine je pense... Cela pourra t'intéressé, c'est en quelque sorte une illustration de la voie du milieu. Mais le milieu de quoi ? Smile

Pingbacks and trackbacks (1)+

Ajouter un commentaire