Un nouveau toolkit MVVM pourquoi ? Vous saurez tout !
Un nouveau Toolkit MVVM
Un nouveau toolkit MVVM fait son apparition, mais pourquoi ? Que vient-il ajouter ou remplacer ? C’est pour répondre à ces questions essentielles que j’ouvre une série d’articles qui vous présenterons ce nouvel outil.
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.
Alors allons-y tout de suite !
La série en 5 parties à lire
MVVM sont les initiales de Model / View / ViewModel, les trois tiers d’une application moderne qui en réalité utilise aussi d’autres paradigmes tels que les services, les micro-services, et d’autres patterns architecturaux. Toutefois MVVM, très proche de MVC ou d’autres patterns de ce type, s’applique principalement dans le champ d’application possédant une interface utilisateur sophistiquée. Dans le monde Microsoft c’est MVVM qui s’est imposé car ce pattern prend en compte la particularité du Binding de XAML et est mieux adapté à ce contexte.
Le Model représente les données utilisées par l’application, la View (vue) l’interface utilisateur graphique (GUI), le ViewModel étant le code permettant de présenter les données du Model à la View mais aussi de prendre en charge les commandes et autres interactions de l’utilisateur avec l’application (et, le plus souvent, de modifier les données du Model en conséquence).
Les avantages de MVVM et des patterns proches sont multiples :
- Meilleure réutilisation du code (DRY)
- Comportements platform-agnostic
- Meilleure testabilité
- Séparation claire entre le code GUI et le code applicatif, permettant une séparation plus nette entre Design et Développement
- Éviter le code spaghetti en proposant un cadre architectural qui a fait ses preuves
Depuis un moment certains toolkits très utilisés sont en perte non pas de vitesse mais de maintenance… Les concepteurs comme les équipes à l’origine de ces toolkits, comme nous, finissent par se lasser ou changer de poste, de vie quand on envisage des durées de plusieurs années. Et c’est un problème pour beaucoup de développeurs attachés à ses toolkits aussi bien que pour ceux qui envisageaient d’utiliser l’un de ces toolkits MVVM.
Par exemple Caliburn.Micro n’est plus maintenant. Bourré de bonnes idées, très complet, il n’est définitivement plus maintenu.
Mais c’est le cas aussi de MVVM Light de Laurent Bugnion. Et là c’est plus problématique car il s’agit du toolkit MVVM le plus utilisé dans les applications réalisées depuis des années : WPF, Silverlight, Windows Phone, UWP, Xamarin.Android, Xamarin.iOS, Xamarin.Forms… Tous les environnements C#/XAML Microsoft ont eu le droit à leur version de MVVM Light. Et ce à l’identique, sans confusion possible.
Certes Prism existe toujours et continue à être maintenu et pourrait être un excellent choix pour aiguiller les développeurs ayant perdu leur outil habituel.
Mais il faut noter plusieurs particularités de Prism qui interdisent une telle démarche, ou qui la rende moins simple et moins efficace qu’il pourrait y paraître.
Tout d’abord Prism n’est qu’un nom. Ce n’est pas un toolkit unique adapté à plusieurs environnements, c’est un code réécrit from scratch pour chaque environnement par des équipes différentes. Ainsi, le Prism original, « le vrai », celui pour WPF que je conseillais à l’époque, n’a absolument rien à voir par exemple avec celui pour WinRT Windows 8 ou UWP. C’est très gênant ces changements d’API on en conviendra (et c’était justement la force de MVVM Light de rester le même partout). Il faut aussi noter que Prism est plus complexe, et pas forcément « meilleur » pour autant. Plus difficile de le faire adopter par des équipes de niveau hétérogène notamment. La documentation de Prism, ce que l’existence de ses différentes versions ne simplifie pas, est soit inexistante soit incomplète, soit non mise à jour. Il devient difficile d’utiliser un toolkit dans de telles conditions. Dernièrement, et de façon rédhibitoire pour nous, l’équipe Prism a annoncé après de longues tergiversations qu’elle renonçait à adapter son système de navigation pour le SHELL de Xamarin.Forms qui est le moyen officiel d’ajouter des menus aux apps.
Pour toutes ces raisons et d’autres encore, il a été décidé de recréer un remplaçant à MVVM Light, assez proche pour rendre les migrations assez faciles, mais résolument moderne, réécrit totalement pour être plus rapide et tirer profit des évolutions de C# et de l’environnement.
Ainsi, depuis 2020, la communauté .NET s’est lancée dans la conception de ce nouveau toolkit. Aidée au départ par Laurent Bugnion – qui considère d’ailleurs que ce dernier est la suite logique de MVVM Light et qu’en conséquence il conseille vivement.
Le nouveau projet est bien entendu Open Source, utilise .NET Standard 2.0 pour la facilité de portage cross-plateforme, cross-technologie, il est optimisé pour une meilleure utilisation du CPU et de la mémoire.
Le Microsoft MVVM Toolkit est ainsi intégré au Windows Community Toolkit, lui-même sous la houlette de la Dotnet Foundation. Microsoft n’est ni l’auteur ni le propriétaire du projet, c’est un projet communautaire, même si bien sûr la société est très impliquée et fournit un appui non négligeable.
Ce papier arrive au bon moment (ou c’est parce que c’est le bon moment que ce papier arrive…) car en effet, après un temps de gestation compréhensible le Microsoft MMVM Toolkit arrive au state de Release Candidat et peut être utilisé dans les nouveaux projets (avec prudence, une RC n’est pas une version finale, mais elle est assez solide).
Pour se faire une idée, au début octobre, l’historique du projet est le suivant (l’arrêté est fait au moment de l’écriture de l’article début octobre, les choses ont bougé depuis forcément !) :
Comme on peut le constater c’est un projet vivant qui évolue à un rythme soutenu et qui en un an est arrivé à la stabilité permettant d’espérer avec confiance une première release officielle pour Novembre 2021, au moment de la sortie de MAUI (Preview 10 ou 11 puisque la V1 est décalée de six mois environ).
NOTA: Le CommunityToolkit.mvvm est aujourd'hui en production.
Le toolkit se partage en quatre grands blocs qui sont :
- ObservableObject (INotifyPropertyChanged)
- RelayCommand (ICommand)
- Messenger (Pub/Sub)
- Inversion de contrôle (IServiceProvider)
Les objets « observables » c’est-à-dire capable de déclencher une notification de changement sont à la base de MVVM et du Data Binding de XAML, on retrouve ce concept dans tous les toolkits MVVM (sous XAML donc).
Les commandes sont des implémentations de l’interface ICommand facilement interfaçable avec le code du développeur. Elles jouent un rôle essentiel dans les interactions de l’utilisateur final avec l’application. On retrouve le concept là encore dans tous les toolkits.
MVVM ayant pour principe le découplage le plus strict possible il rend impossible (par principe) certaines communications par exemple un ViewModel ne peut pas connaître la Vue qui lui est attachée (en réalité aucun élément ni classe d’UI), un élément du Model ne peut pas connaître un ViewModel précis, etc. Deux ViewModels ne peuvent même pas se connaître. Entendre « se connaître » comme un équivalent à un « using xxx ; ». De fait il faut trouver un moyen non pas d’autoriser (ce serait violer le pattern) mais de permettre ces communications qui souvent sont indispensables. C’est la messagerie qui joue ce rôle sous MVVM et c’est tout naturellement un élément qu’on retrouve dans tous les toolkits.
L’inversion de contrôle comme l’injection de dépendances sont un « plus », une aide précieuse pour le découplage. Cela permet, via des interfaces, au code d’appeler des services rendus par d’autres parties du code sans avoir à « se connaître » (au sens indiqué plus haut).
Au tout début des travaux sur le MS Toolkit il y avait une hésitation entre reprendre le SimpleIoC de MVVM Light, simple et très léger, ou utiliser le module existant de chez Microsoft, un peu plus lourd mais plus complet. L’adoption de l’interface IServiceProvider permet de régler le problème est rendant l’implémentation du moteur d’IoC indépendant du toolkit. Par défaut celui-ci utilise le moteur Microsoft désormais, mais chacun peut utiliser celui qu’il préfère.
Fin de la partie 1
Ce billet de blog 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 !