Un nouveau toolkit MVVM pourquoi ? Vous saurez tout !
Suite…
Le 12 novembre dernier j’ai entamé une série d’articles sur le nouveau toolkit MVVM intégré au Windows Community Toolkit (WCT). Ce toolkit MVVM est cross-plateforme, écrit à partir de zéro en .NET Standard 2.0, et sa première motivation est de remplacer MVVM Light et Caliburn.Micro dont la maintenance a été définitivement arrêtée.
Vous pouvez retrouver la Partie 1 en cliquant sur cette phrase !
Nota: Depuis l'écriture de cette série de papiers, le Toolkit MVVM a été transféré dans le Community Tookit et le namespace à installer est CommunityToolkit.Mvvm.
Aujourd’hui continuons la présentation de ce nouvel outil qui deviendra certainement l’un de vos favoris dans vos prochains projets…
La série en 5 parties à lire
L’article précédent se terminait par la présentation des 4 grands blocs qui constituent le toolkit. Mais ils ne sont qu’une approximation très grossière de ce que contient le toolkit. Bien que résolument simple, dans la lignée de MVVM Light ne l’oublions pas (Light = léger !), il contient tout de même certains ajouts qui avec le temps étaient devenus nécessaires.
Par exemple on va trouver des notifications liées aux tâches (Task) qui permettent notamment d’effectuer une notification INPC une fois qu’une certaine tâche liée à la modification d’une valeur de propriété sera terminée (afin que les utilisateurs de la valeur puissent voir uniquement la nouvelle valeur une fois qu’elle sera créée).
On trouve aussi des méthodes ou objets simplifiant l’implémentation des ViewModels, des propriétés et leur setter, voire même des ViewModels offrant l’interface INotifyDataErrorInfo pour la gestion des validations de saisie.
Il existe aussi deux nouvelles commandes qui prennent en charge l’asynchronisme avec annulation possible en cours de travail.
Tout le code ayant été réécrit dans le but d’une plus grande vitesse et d’une consommation mémoire maîtrisée, la messagerie utilise par exemple des WeakReference. Si cela prévient des fuites mémoire il s’agit d’une indirection qui coûte en vitesse d’exécution. Pour les cas (rares) où la rapidité d’exécution ou la consommation mémoire liée aux messages priment sur les éventuels memory leaks, il existe une seconde messagerie n’utilisant que des références fortes (strong references). Elle est bien plus rapide et autorise l’utilisation de la messagerie dans du code où la vitesse est cruciale.
Parmi les avancées en cours, le toolkit a pour ambition de rendre encore plus simple son utilisation en exploitant la génération de code de Roselyn. En plaçant quelques attributs il sera donc possible d’écrire des propriétés complètes juste en partant d’une simple définition de champ privé par exemple. Le code sera généré à la volée et mis à jour en temps réel durant la frappe dans Visual Studio.
Un exemple est donné par la capture ci-dessous, à gauche le code tel qu’on l’écrit « classiquement » avec le toolkit, à droite le code qu’on peut écrire en tirant profit du générateur de code source :
Il s’agit d’option, et chacun pourra choisir d’utiliser ou non cette extension. Les raisons principales de s’en servir : rapidité de frappe, moins de code, moins d’erreurs possibles, code plus concis, plus facilement lisible, programmation par intention, etc. La seule raison de ne pas s’en servir pourrait se cacher dans la pérennité. Tous les toolkits meurent un jour, le MS MMV toolkit est là pour nous le rappeler puisque même des stars comme MVVM Light ou Caliburn.Micro par leur disparition ont entraîné la création du nouveau toolkit. Ce dernier viendra forcément un jour à être remplacé ou à disparaître. Ce jour-là votre code sera toujours utilisable très certainement (le code C# et .NET ont survécu à toutes les évolutions jusqu’ici), mais si l’extension de génération ne fonctionne plus ou n’existe plus, vous ne récupérerez qu’un code avec de jolis attributs sans code fonctionnel derrière. Il faudra donc réécrire ce que le générateur avait écrit pour vous automatiquement.
Personnellement je n’aime pas que mon code soit lié à l’existence d’outils externes. Il doit être complet et fonctionnel et surtout se suffire à lui-même au moins sur l’essentiel.
Il existera donc des petits projets à durée vie courte pour lesquels la génération semble apporter plus d’avantages que d’inconvénients. Et des projets plus lourds ou s’inscrivant dans une durée plus longue pour lesquels il faudra, à mon avis, favoriser l’autonomie du code vis-à-vis des outils de développement et des toolkits.
Mais on peut déjà noter que ce type d’extension utilisant la génération de code de Roselyn marque plutôt le futur de ce que seront les outils dans les années à venir, sans compter sur l’IA qui fera son apparition bientôt pour aider à coder ou même se substituer au développeur dans certains cas… Nul n’est l’abris de l’IA ! L’informaticien de base est assis sur une branche que des informaticiens plus qualifiés sont en train de scier…
Avant d’entrer dans le vif du sujet, et même si de nombreuses informations données jusqu’ici le laisse entendre, il semble essentiel de préciser que le Microsoft MVVM Toolkit est dès sa conception totalement cross-plateforme.
L’adoption de .NET Standard 2.0 comme seule dépendance permet d’utiliser le toolkit sur toutes les plateformes supportées par .NET, sachant – mais ce serait un autre sujet bien long à traiter – que la version 5 comme la 6 à venir ne sont que la suite des premières versions de .NET CORE. Le mot « CORE » (noyau) était utilisé à la base car .NET CORE se destinait plutôt aux serveurs. Un code .NET plus rapide à exécuter, plus facile à installer et à packager avec les applications, etc. Toutefois dans son aventure qui l’amène aujourd’hui à devenir le standard unificateur il a semblé, assez légitimement, à Microsoft que le mot « CORE », « noyau » donc, pouvait prêter à confusion plus qu’autre chose. Et depuis .NET CORE 5.0, on parle de .NET 5 tout court, tout comme la version de suivante s’appellera .NET 6 alors qu’il s’agira bien d’un .NET CORE 6. On peut facilement se tromper si l’on considère que la dernière version du « framework .NET » est la version 4.8 d’avril 2019, ce qui ferait de « .NET 5 » son successeur logique. Il s’agit d’une pure coïncidence, les versions de CORE et du framework ayant évolué chacune de leur côté depuis longtemps sans qu’une telle convergence n’ait été diaboliquement planifiée ! Mais parfois le hasard fait bien les choses…
Donc le toolkit MVVM a été conçu pour être cross-plateforme dès le départ, identique à lui-même (pas des versions différentes comme Prism), utilisable aussi bien sous UWP que WPF, Xamarin.Forms, MAUI et WinUI3.
Fin de la partie 2
Ce billet de blog comme le précédent dépasse déjà la taille d’un article papier… Aller plus loin ici serait déraisonnable. Je vous invite donc à suivre la suite dans le prochain billet !
Stay Tuned !