MVVM : arretons l’enfumage

Certains petits malin ont pris pour habitude de faire peur au jeune souhaitant apprendre la programmation en .Net. En effet après les avoir laissé barboter entre la pataugeoire du xaml et le

tobogand du code behind, ces “programmeur confirmé” vont insidieusement et avec les meilleures intentions du monde les diriger vers les posts sur le MVVM. Et là c’est le drame !

Ces jeunes programmeurs vont tomber sur des posts aussi variés et hors de sujet que les superbes introductions du MSDN, les post sur MVVMLight ou Prism ou encore certains posts ou certaines vidéos rendant très compliqué le moindre concept.

Et le pire sur les forums on va leur dire que :” est-ce que c’est vraiment adapté à leurs situations…. et est-ce que ce serait pas juste un outil pour l’accès aux données dont ils n’aurait pas besoins et est-ce qu’il vaudrait mieux utiliser prism direct”…. Bref un tas de conneries.

Le MVVM c’est simple et ça s’applique partout !!!!!

Comment ?

Il faut se le représenter comme un jeu : le but du jeu et de ne plus rien mettre dans le code behind.

L’idée est d’utiliser toute la puissance du système de Databinding.

Imaginez vous êtes dans le futur en 2124 vous allez acheter un gâteau du futur dans un supermarché de l’espace. Et ben votre  et votre ViewModel c’est votre gâteau et votre View c’est l’emballage. Il est génial parce que c’est lui qui va chercher les informations sur le gâteau qu’il contient et qu’il va les afficher. Petit exemple votre gâteau est au chocolat et pèse 250g et contient de la noisette aussi. et ben votre emballage ayant ces informations à disposition va de lui-même les afficher. Si le poids du gâteau change parce que vous avez changé de planète entre temps l’emballage va de lui-même aller chercher l’information du nouveau poids et vous l’afficher.

Arrêtons les métaphore douteuses une seconde et revenons sur ce principe : L’idée principale c’est : le coeur de l’application (VM&M&DataAccesLayer...) expose des informations. Il expose aussi des moyens d’agir sur ces informations donc par exemple : Il va exposer le nombre de part restantes de notre gâteau de l’espace et va exposer une commande pour manger une part de ce gâteau. C’est l’emballage (la vue) qui va dire : cette information m’intéresse je veux la prendre l’afficher comme je veux et être prévenu si elle change. Voilà elle est là la force du Databinding l’emballage et le gâteau sont deux objets distincts et n’ont pas de liens ils vont se transmettre des notifications, exposer des propriétés (pour le VM) et s’abonner (pour les Vues) . Une dernière comparaison pour bien comprendre le coeur de votre application devrait toujours ressembler à une sorte de gros noyaux (dans le cas où elle n’est pas modulaire) d’où sortirait des accroches sur lesquels les vues pourraient venir s’amarrer et qui seraient des canaux de communication.

 

Dans tous mes exemples il est bien entendu possible que plusieurs vues observent les propriétés d’un même VueModele. Il est évident aussi que si l’utilisateur souhaite agir sur le modèle et il faut que la vue puisse agir sur la VM. Pour ce faire la où les VM expose des leviers d’action aux vues. Celles-ci sont libre de dire : je souhaite pouvoir actionner ce levier d’action avec ce bouton de la manière dont je le souhaite (par un click ou par un évènement tactile ou autre …) et ce levier va ensuite actionner un changement dans la VM.

Pour résumer : L’idée est de reverser son système de pensés : le logiciel ne se construit plus en partant de l’interface mais, en partant du noyau (composé de VM et de M etc) et c’est ensuite qu’on va venir emballer notre application dans des vues et montrer les données du système comme on le souhaite.

Il y a quelque chose de génial à cela : dans la vraie vie je vous souhaite pouvoir changer de style vestimentaire régulièrement, les modes et notre époque évoluent vite. Or ici c’est pareil : le client après un projet peut vous demander de rajouter des fonctionnalités (on verra comment le faire proprement dans un autre post) ou alors plus communément vous demander d’actualiser ou de changer l’interface de son application. Vous pourrez donc lui dire avec fierté qu’il ne vous faudra que quelques jours pour effectuer le changement, car vos vues sont interchangeables et indépendantes et vous verrez la reconnaissance dans ses yeux (et dans votre porte feuille également).

 

Pourquoi ?

Certains parmi débutants, dont je fait parti il y a très peu de temps me répliqueront : Pourquoi ?

Pourquoi s’embêter à s’imposer des contraintes pareilles. Pour eux le code behind est un outil fantastique et ils ne voient pas pourquoi ils devraient se passer de mettre du code à l’intérieur.

Je leur répondrais que pour un petit projet avec trois boutons ce n’est pas une évidence d’utiliser le MVVM mais, dès que le projet grandi cela devient la seule manière de le maintenir sans ramer dans un océan de code spaghetti.

En réalité au lieu de venter les mérites de cette méthode il vaut mieux expliquer ce qui se passe si elle n’est pas utilisée.

Si un projet se contente des contrôles et fenêtres classiques et de leur code behind tout va très vite devenir interdépendant et ça c’est très mauvais, car quand tout est lié votre code est un bloque ou chaques changements que vous voudrez faire, deviendra un combat de tous les moments pour que votre application entière ne s’écroule pas.

L’interdépendance est l’ennemi d’un projet informatique. Votre application deviendra de plus en plus compliqué à maintenir même avec la meilleure structure du monde et vous ne pourrez pas tester la plupart de votre code, car les tests unitaires sont quasiment impossible à mettre en place dans le code behind (et oui vous n’avez qu’une partie des informations dans celui-ci ).

Mon dernièrs argument est celui qui en général, a le plus de mal à passer mais c’est le plus important : Penser à celui qui passe après vous. Même quand vous êtes stagiaire pensé que dans certaines entreprises votre code va être repris par un autre ensuite et qui lui n’est pas dans votre tête et ne pense pas comme vous. Alors, pour qu’il ne fasse pas une dépression chronique en voyant votre tas de spaghetti il faut découpler votre code en faire des petits morceaux indépendant, communiquant et stable.

 

Enfin pour ceux qui disent que tout ceci prend du temps et qu’il faut prendre en compte le coup de développement : c’est vrai mais, pensez bien à la mine réjouit de votre employeur quand il reviendra vous voir à la fin du projet pour la dernière modification inattendu et que vous pourrez la faire sans mobiliser des mois de travail à tout modifier. Penser bien que si vous démarrez votre projet sur les chapeaux de roue sans penser à la structure et à l’évolutivité et autant que vous pourrez gagner par la suite vous avez beaucoup plus de chance de vous planter.

Quels chiffres pour aérer un peu : le temps dans un projet de développement se répartit comme ceci : 15% de développement pure , 25% de réunion à la con avec dedans 5% de recueil du besoin et 60% du temps sera consacré à maintenir ce logiciel . 60% de votre temps ça compte donc ne le rendez pas plus difficile à passer.

Simplifiez votre vie future de développeur

Dans un prochain post (plus court que celui-ci ^^), je vous montrerais comment réaliser simplement un petit programme en MVVM

 

 

 




Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>