Discussion :

[RichardW2C]

Bonjour,

Oui, oui, je sais, c’est « le » pattern utilisé pour les UI, particulièrement adapté à WPF, il parait. Et pourtant… Je doute. Et au moment d’engager un nouveau projet, je me demande si cette architecture serait vraiment utile. Je précise que l’équipe de développeurs est petite, il n’y a pas de designer à plein temps ou d’intégrateur. Souvent, c’est le même dev qui fait à la fois le code des objets métier, DAL et UI, pour un projet donné ou une branché donnée.

Après avoir lu au sujet du MVVM et vu quelques exemples, j’ai l’impression que pour un projet impliquant une grosse équipe, avec peut-être des gens travaillant sur des lieux différents, et avec plusieurs rôles (comme designer, ergonome, intégrateur, etc.) le MVVM offre une panoplie lourde mais utile. Mais à part dans ce genre de circonstances, je doute. Et un avis d’expert du MVVM (qui fréquente parfois ces forums) alimente mon doute : http://www.e-naxos.com/Blog/post/201...ern-MVVM-.aspx . Je trouve que ces arguments sont forts et se tiennent bien.
Et vous ? Utilisez-vous le MVVM ? Si oui, pourquoi ? Quels avantages concrets en avez-vous tirés ? Si non, quelles raisons pour ne pas l’avoir adopté ?

Merci

[DonQuiche]

Bonsoir.

J'ai envie de répondre que tous les patterns, s'ils sont appliqués de façon dogmatique et aveugle, conduisent à des systèmes tordus et étouffants. Certes, MVVM peut vraiment repousser ces limites. Cela dit, il reste séduisant et parfois commode. Et si l'on reste pragmatique, qu'on n'hésite pas à violer le pattern quand nécessaire pour mettre en place des choses plus simples via du bon vieux code-behind, bref que l'on mijote sa propre tambouille en accord avec le reste de l'équipe (quand celle-ci est de taille raisonnable) et en picorant des éléments ici ou là (commandes construites à partir d'un simple lambda comme on en trouve ici ou là dans plusieurs frameworks), mon avis est qu'on obtient alors de bons résultats, pas pires que ce que l'on obtient avec d'autres patterns, surtout lorsqu'ils sont appliqués à des WPF/SL vraiment taillés pour MVVM (Blend ou les treeview virtualisés, par exemple).

En somme, l'article est très bien écrit et je le rejoins sur tous les points, y compris la conclusion selon laquelle la solution n'est pas de totalement abandonner MVVM mais de le bricoler. Quant aux détails, encore une fois, c'est à régler avec l'équipe.

[yonpo]

Salut,

J'ai adopté récemment MVVM et je dois dire que j'étais assez réfractaire à l'utiliser. J'avais l'impression que c'était une usine à gaz et que ça casserait quelques habitudes de programmation.
Après quelque effort d'apprentissage, j'en suis très satisfait. Il faut, je crois, faire le trie entre ce que propose le pattern et ce dont tu as besoin.
Etant exigeant sur la structure d'un projet (séparation, découpage) et sur le travail bien fait, MVVM a répondu à mes besoins.

Ces arguments reviennent souvent, mais la taille du projet entre en compte dans le choix de MVVM, tout comme le maintenabilité de celui-ci (le projet devra-t-il évoluer ? des changements fréquents sont-ils possibles (en industrie cela arrive souvent, modification technique des produits) ? ).

Autrement, en ce qui concerne le travail en équipe je ne peux pas me prononcer car je suis seul développeur dans mon entreprise (eh oui je fais tout ).

Enfin, j'ai dû recemment modifier pas mal l'UI d'une application car cela ne convenait plus au boss. Du coup, ayant aucun code dans le code behind, les changements se sont fait facilement (merci les commandes et le binding).

[Crooby]

Salut,

suite aux réponses, voici quelque outils sympas pour le mettre en oeuvre facilement:

http://mvvmlight.codeplex.com/

http://caliburn.codeplex.com/

Et je trouve qu'on exploite vraiment toute sa puissance en le combinant à MEF
qui permet de faire de l'injection de dépendances et de rendre son application modulaire (plugins)

http://mef.codeplex.com/

[Thomas Lebrun]

Et vous ? Utilisez-vous le MVVM ? Si oui, pourquoi ? Quels avantages concrets en avez-vous tirés ? Si non, quelles raisons pour ne pas l’avoir adopté ?

Facilité d'écriture des tests unitaires, simplicité/lisibilité du code, séparation code/design.... Rien que pour cela, MVVM est un grand plus (ceux qui ont déjà développés des applications WPF sans MVVM seront très certainement d'accord avec moi )

[Invité]

Facilité d'écriture des tests unitaires, simplicité/lisibilité du code, séparation code/design.... Rien que pour cela, MVVM est un grand plus (ceux qui ont déjà développés des applications WPF sans MVVM seront très certainement d'accord avec moi )

Oh le grand maître est trop modeste et ne veut pas faire la pub de son livre. Bref le disciple le fera pour toi alors.

RichardW2C, franchement si tu as besoin de comprendre à fond ce pattern je te conseille ce bouquin fais par Thomas et Jmix90 => MVVM. De la découverte à la maîtrise ici.

[RichardW2C]

Bonsoir.

J'ai envie de répondre que tous les patterns, s'ils sont appliqués de façon dogmatique et aveugle, conduisent à des systèmes tordus et étouffants. Certes, MVVM peut vraiment repousser ces limites. Cela dit, il reste séduisant et parfois commode. Et si l'on reste pragmatique, qu'on n'hésite pas à violer le pattern quand nécessaire pour mettre en place des choses plus simples via du bon vieux code-behind, bref que l'on mijote sa propre tambouille en accord avec le reste de l'équipe (quand celle-ci est de taille raisonnable) et en picorant des éléments ici ou là (commandes construites à partir d'un simple lambda comme on en trouve ici ou là dans plusieurs frameworks), mon avis est qu'on obtient alors de bons résultats, pas pires que ce que l'on obtient avec d'autres patterns, surtout lorsqu'ils sont appliqués à des WPF/SL vraiment taillés pour MVVM (Blend ou les treeview virtualisés, par exemple).

En somme, l'article est très bien écrit et je le rejoins sur tous les points, y compris la conclusion selon laquelle la solution n'est pas de totalement abandonner MVVM mais de le bricoler. Quant aux détails, encore une fois, c'est à régler avec l'équipe.

C'est la voie sur laquelle je vais m'engager, je pense. Trouver ce qui peut être utile, le proposer à l'équipe, et garder une certaine souplesse.

Salut,

J'ai adopté récemment MVVM et je dois dire que j'étais assez réfractaire à l'utiliser. J'avais l'impression que c'était une usine à gaz et que ça casserait quelques habitudes de programmation.
Après quelque effort d'apprentissage, j'en suis très satisfait. Il faut, je crois, faire le trie entre ce que propose le pattern et ce dont tu as besoin.

Usine à gaz, c'est l'impression que cela donne, oui .

Et je trouve qu'on exploite vraiment toute sa puissance en le combinant à MEF
qui permet de faire de l'injection de dépendances et de rendre son application modulaire (plugins)

http://mef.codeplex.com/

Merci pour la référence

Facilité d'écriture des tests unitaires, simplicité/lisibilité du code, séparation code/design.... Rien que pour cela, MVVM est un grand plus (ceux qui ont déjà développés des applications WPF sans MVVM seront très certainement d'accord avec moi )

Mais que penses-tu des critiques d'Olivier ? Critiques qu'il faut bien comprendre : il ne propose pas d'abandonner le MVVM, en fait, mais d'en quelque sorte prendre du recul.

Oh le grand maître est trop modeste et ne veut pas faire la pub de son livre. Bref le disciple le fera pour toi alors.

RichardW2C, franchement si tu as besoin de comprendre à fond ce pattern je te conseille ce bouquin fais par Thomas et Jmix90 => MVVM. De la découverte à la maîtrise ici.

J'ai ce livre, depuis peu, enfin, la version streaming. Je la déconseille, en fait, mieux vaut acheter la version PDF ou papier.

Je n'arrive d'ailleurs pas à faire tourner le code exemple. Il compile, mais à l’exécution avec l'erreur :

Message='La propriété 'Resources' a déjà été définie sur 'App'.' numéro de ligne '30' et position de ligne '11'.
Source=System.Xaml
LineNumber=30
LinePosition=11

et du coup, une autre erreur apparaît :

Error 1 Invalid XmlnsDeclaration occurs in assembly 'JetPackWPFTheme, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. XmlnsDeclaration references a namespace 'JetPackWPFTheme' that is not in the assembly. C:\Users\richard\Documents\CSharp\Exemple de code MVVM\MVVMReady\MVVMReady.Main\App.xaml 1 1 MVVMReady.Main

Ce livre est intéressant et bien construit. Mais bon, il fait quand même - à mon humble avis - un peu usine à gaz. Un modèle, un modèle client, et un tas de choses qui oui, découpent bien la solution en tranches, mais difficilement exploitable pour moi. Là, je gère le passage à une nouvelle version d'un produit déjà existant, et il me faut tenir compte de ce qui existe, sans avoir à refaire toute l'architecture.

[yonpo]

Je n'arrive d'ailleurs pas à faire tourner le code exemple. Il compile, mais à l’exécution avec l'erreur :

Message='La propriété 'Resources' a déjà été définie sur 'App'.' numéro de ligne '30' et position de ligne '11'.
Source=System.Xaml
LineNumber=30
LinePosition=11

Mets ces lignes (32 à 92) en commentaire.

[tomlev]

Personnellement j'étais assez réfractaire à WPF au début, je trouvais ça super compliqué par rapport à Windows Forms. C'est à partir du moment où j'ai commencé à utiliser le pattern MVVM que j'ai trouvé ça génial

[RichardW2C]

Mets ces lignes (32 à 92) en commentaire.

Merci !

Sinon, merci pour vos retours d'expérience.

[Thomas Lebrun]

Un modèle, un modèle client, et un tas de choses qui oui, découpent bien la solution en tranches, mais difficilement exploitable pour moi.

Je pense que tu viens de mettre le doigt sur quelque chose d'important: tu as l'impression que c'est difficilement exploitable mais quelqu'un habitué à un projet avec un vrai découpage en couches ne sera pas perdu

Là, je gère le passage à une nouvelle version d'un produit déjà existant, et il me faut tenir compte de ce qui existe, sans avoir à refaire toute l'architecture.

Ce qui est sur, c'est que mettre en place MVVM sur un projet déjà existant, un peu gros, c'est revoir/refaire une bonne partie de l'architecture.... Mais si au final, cela permet d'y voir plus clair, de simplifier les choses, c'est une étape par laquelle il faut passer

A+

PS: Désolé pour la coquille dans le code du livre, on essaye de mettre une MAJ du code dès que possible
PS2: Il n'y a pas de version streaming du livre, juste du PDF ou du papier....

[alves.seb]

Par expérience je trouve que MVVM est très bonne solution à partir du moment où il est correctement utilisé. Malheureusement j'ai vu pas mal de dérive où les projets pouvaient devenir des usines à gaz.

Ce n'est pas parce que l'on met un label MVVM devant un projet qu'il sera forcement irréprochable.

Mais globalement si la démarche est respectée, MVVM reste une excellente pratique aujourd'hui pour construire des applications testables, lisibles et qui respectent la séparation code/design.

[RichardW2C]

Merci pour vos réponses. J'ai finalement décidé d'utiliser le MVVM, avec Silverlight et Jounce.