Blog de Nico-pyright(c)

17
juin
2011

Un article de nico-pyright(c) Comments

J’ai lu il y a quelques temps un billet d’Olivier Dahan où, par un titre accrocheur, il proposait son retour d’expérience sur MVVM en proposant de bruler le pattern (voir http://www.e-naxos.com/Blog/post/2011/05/20/Faut-il-bruler-la-pattern-MVVM-.aspx)

Comme ca fait quelques temps que je n’ai pas écrit de billet et que j’ai envie de partager mon expérience sur le sujet, j’en profite

Je suis globalement d’accord avec lui, respecter tout MVVM n’est pas forcément toujours judicieux. Il faut l’adapter aux besoins de l’application.

En général, j’adapte mon utilisation de MVVM en fonction de l’application que je crée. Par contre, aujourd’hui, je ne concevrai pas de créer une application sans MVVM.

Je trouve que le découplage est beaucoup plus clair et j’ai remarqué pour ma part que j’écris plus rapidement mon application en utilisant un viewmodel qu’en utilisant le code behind. De même, un ressenti totalement subjectif et pifométrique me fait trouver que je fais moins de bugs.

Donc, une application sans mvvm ? non. Maintenant que j’y ai gouté, je ne peux plus m’en passer. Par contre, suivant l’application, je respecte plus ou moins le pattern.

Je trouve qu’un des valeurs ajoutées du pattern est qu’il force à utiliser le mécanisme de binding. Il est trop tentant (pour aller vite) de faire du monTextBlock.Text = “…”.

Pour moi ca n’apporte rien, à part des bugs

J’ai vu trop de gens ne rien comprendre au binding et c’est bien dommage. Donc oui au binding, forcé par mvvm.

Je suis d’accord qu’on peut se demander vraiment l’utilité d’un locator et en général, pour une petite application rapide, je ne m’en sers pas. Par contre, je rajoute dès que possible l’utilisation des commandes, notamment grâce à la classe RelayCommand qu’on trouve dans MVVM-Light.

Il est vrai que pour une application rapide, pour un test ou autre, j’ai tendance à ne pas embarquer de dépendances (donc pas de RelayCommand ou autres systèmes de messagerie) et donc j’utilise le code-behind pour récupérer mon viewmodel et lancer les commandes. Ca créé un couplage, mais est-ce bien grave ?

Par contre, dès que l’application est un tant soit peu sérieuse, on ne peut pas s’en passer.

Je partage également le point de vue d’Olivier qui dit qu’on peut vite se perdre avec un système de messagerie (je n’utilise pas celui de MVVM-Light). J’ai l’impression de m’en sortir mieux maintenant en me fixant quelques règles de nommages, d’utilisation. Il est vrai qu’il n’y a pas de guidelines pour et qu’au démarrage on peut vite s’embrouiller… mais avec un peu de pratique, je trouve qu’on peut l’utiliser avec profit.

Les boites de dialogues ? Oui, c’est vrai, c’est casse-pied Mais comme j’ai tendance à ne pas trop en faire et plutôt à afficher des confirmations sous une autre forme, ca ne m’embête pas trop trop. Quand j’en ai besoin, le système de messagerie me rend bien des services.

Les tests unitaires ? J’ai beau être un adepte convaincu du testing, j’avoue ne pas m’en servir pour tester les viewmodels. Je préfère blinder la couche d’accès aux données ou la couche de service.

Dans un des commentaires, on peut lire une remarque sur la création de contrôles personnalisés remplies de DependencyProperty juste pour faire du MVVM qui, pour le commentateur, est un problème. Il est vrai que créer des contrôles utilisateurs juste pour ca, c’est un peu dommage. Par contre, dans certains cas, je trouve que ca apporte un découplage complémentaire et offre une réutilisabiilté. Certains behavior sont tout à fait pertinent.

Bref, voici mon retour d’expérience.

En conclusion : Oui pour MVVM, il faut dans un premier temps faire dans l’extrémisme pour pouvoir comprendre et apprécier les avantages du patron de conception et ensuite y revenir et l’adapter vraiment au besoin.

Identifiez-vous

Créer un compte

Blog de Nico-pyright(c)

Laisser un commentaire

Articles récents

Commentaires récents

Archives

Catégories

Méta

Identifiant
Mot de passe

Mot de passe oublié ?