Depuis le temps que je l’explique à mes clients et que je l’écris sur Twitter, me voilà bien content de découvrir ce soir que je ne suis plus le seul à dire que le design pattern MVVM est à utiliser avec modération sur les projets Silverlight et WPF. Permettez-moi de vous livrer ici mon critère pour savoir si vous devez ou non faire du MVVM sur votre projet.
“On m’aurait menti? MVVM n’est pas la panacée?”
“Alors dans quels cas choisir MVVM?”
Mon travail d’expertise m’ayant amené à intervenir sur plusieurs dizaines de projets Silverlight/WPF, j’ai pu en tirer une conclusion simple sur l’usage ou non de MVVM. Voici comment décider simplement si MVVM fera du bien ou non à votre projet.
Répondez au questions suivantes:
- Y-a-t-il plus de 4 développeurs sur le projet?
- Est-ce que les développeurs vont réaliser une bonne dose de tests unitaires automatisés?
- Est-ce que la maquette est faite et validée, donc que les entrées/sorties sur les écrans changeront peu?
Vous avez répondu “oui” à deux questions au moins? MVVM est fait pour votre projet (une formation MVVM pour votre équipe?). Sinon, mon conseil: évitez MVVM sur ce projet.
“C’est simple, mais il faut un nom à cette règle, pour faire pro”
C’est vrai que “théorème d’Archimède” ça fait plus classe que “le truc qui fait que ça flotte”. Alors si vous voulez un nom je vous propose d’appeler là règle ci-dessus “critère d’épo”. Pourquoi? Parce qu’epo c’est mon pseudo Twitter et qu’il vous fallait un nom, n’est-ce pas? Sinon appelez ça “théorème du consultant Silverlight”, ça ira aussi bien.
Un témoignage sur MVVM? Pas d’accord avec moi? Vos commentaires sont les bienvenus.
Comments