Dot.Blog

Tout change tout évolue comme je le disais dans mes derniers articles. Prism ce framework lié à WPF est désormais disponible en cross-plateforme pour les Xamarin.Forms…

Prism et MVVM

Prism est aujourd’hui une librairie MVVM. Elle nous vient du fin fond des âges (informatiques donc pas très loin), de WPF.

Prism a toujours été considéré comme un framework un peu complexe, et à juste titre. Sous WPF il est bien plus complet que MVVM Light mais cela se paye par des configurations, des conventions qui n’en font pas, à mon avis, un framework pour toutes les équipes. Seules celle qui sont homogènes peuvent tirer profit de Prism. Pour les autres cela est plus délicat, notamment lors de l’intégration de développeurs novices ou de moins bon niveau. Mvvm Light par sa simplicité de mise en œuvre s’adapte mieux à des contextes hétérogènes.

Au début Prism fonctionnait pour WPF, était assez complexe et surtout ne parlait pas de MVVM en se réclamant plutôt de MVC. Certes ce n’est pas bien loin mais cela en disait beaucoup sur l ‘esprit de ceux qui produisait cette librairie.

En 2012/2013 Prism a été refondu à partir de zéro pour supporter WinRT. J’ai travaillé avec l’équipe de Prism à cette époque au sein du Developer Guidance Advisory Council Microsoft. J’ai d’ailleurs proposé une série sur Prism pour WinRT en juillet 2013 (suivez le lien vers l’historique de dot.blog vous y trouverez ces articles).

A cette occasion Prism, entièrement refait et totalement différent du Prism pour WPF, a pris une direction nouvelle utilisant mieux les possibilités de .NET et de C#, simplifiant ce qui était trop lourd. Mais perdant un peu de sa sophistication. Bien qu’aillant participé au projet je n’ai jamais caché mes doutes quant à l’adéquation avec WinRT qui ne me semblait pas taillé pour faire du LOB.

Depuis Prism a continue son évolution. Notamment sous la houlette de la .NET Foundation.

Basé sur les grandes modifications de Prism pour WinRT plus que sur le Prism original pour WPF, Prism est devenu une librairie totalement MVVM et cross-plateforme.

Après Mvvm Ligth, MvvmCross, Caliburn.Micro, Prism vient rejoindre le clan du multi OS, ce cross-plateforme dont je vous parle depuis plus de trois ans en vous disant que c’est l’avenir. Or l’avenir c’est maintenant… Bienheureux ceux qui m’ont suivi depuis ces années et qui par le fait sont certainement mieux préparés à cette réalité !

Prism est désormais un ensemble cohérent qui s’adapte aux projets WPF, UWP et plus récemment Xamarin.Forms !

Prism et les Xamarin.Forms

Dans une grande cohérence Microsoft pousse tous ses projets dans le même sens, le cross-plateforme. Après le rachat de Xamarin qui a permis de consolider ce positionnement, Microsoft n’en finit plus de proposer des outils fonctionnant sur tous les OS. Je parlai dans un article récent de Visual Studio Code qui en est un excellent exemple (tournant sur PC, Mac et Linux).

Les Xamarin.Forms qui permettent de faire du natif sur toutes les plateformes en utilisant C# et XAML ne pouvaient échapper longtemps à la couverture de Prism.

C’est chose faite donc.

Il devient ainsi possible d’appliquer les mêmes principes à UWP, WPF et Xamarin.Forms, de rendre le code encore plus facilement portable entre ces environnements, et pour cause, en dehors de WPF qui reste à part, en travaillant sous Xamarin.Forms on cible iOS, Android mais aussi UWP donc les PC. Il existe ainsi plusieurs façon d’entrer le circuit avec Prism : soit sous WPF, soit en pur UWP avec le Prism adapté, soit par les Xamarin.Forms qui débouchent aussi sur du natif UWP.

Au passage on l’a compris, le seul vrai choix aujourd’hui pour développer c’est soit WPF soit les Xamarin.Forms…

Avantages ?

Les principes retenus lors de la refonte de Prism à l’époque de WinRT étaient bons (je ne dis pas ça parce que j’y ai participé !). Plus de simplicité, respecter strictement MVVM en le disant clairement, offrir certains automatismes, etc. C’est WinRT auquel je n’ai jamais cru (mais que j’ai loyalement soutenu) qui posait problème dans ce mariage, pas Prism.

Pour vous faire une idée vous pouvez lire mes articles sur Prism pour WinRT que je ne fais pas refaire juste en changeant le titre… Certes il y a eu quelques changements depuis, mais pour comprendre l’esprit de Prism tel qu’il est aujourd’hui c’est un bon début.

Faut-il utiliser Prism ou MvvmCross ou Mvvm Light, voire Caliburn ?

C’est la question qu’on me pose en général quand je parle de l’une de ces librairies. Autant y répondre tout de suite.

Les Xamarin.Forms à la différence des autres versions de XAML est construit pour respecter MVVM, par design. Comme je le montre dans mon livre sur les Xamarin.Forms Il manque très peu de chose aux Xamarin.Forms pour pouvoir se passer d’une librairie supplémentaire. On y retrouve de base une messagerie MVVM, un système d’injection de dépendances et le support des commandes, le binding étant géré de base par XAML.

J’ai réalisé certains projets en me passant totalement d’une librairie externe mais en devant ajouter quelques classes pour plus de souplesse. Par exemple pour les ViewModels la classe de base offerte par Mvvm Light est plus pratique (elle gère INPC avec des variantes qui raccourcissent l’écriture des propriétés par exemple, ou qui permettent de transmettre un message MVVM automatiquement sur le changement d’une telle propriété).

Il est donc tout à fait possible d’appliquer correctement MVVM avec les Xamarin.Forms sans rien ajouter en dehors de quelques bouts de code pour rendre l’ensemble plus pratique.

C’est dans ces bouts de code que ce cache la faille qui permet de dire aussi qu’il est tout à fait censé d’adopter une librairie spécialisée plus complète. Cela peut aussi être intéressant par cohérence avec du code existant. Si vous avez beaucoup de code qui utilise Mvvm Light il sera plus facile de le réutiliser en choisissant Mvvm Light sous Xamarin.Forms… c’est une lapalissade. Il en va de même pour les habitudes prises par les développeurs.

Prism possède son propre “caractère”. Par exemple un couplage automatique entre Views et ViewModels basé sur une convention de nommage (qu’on peut modifier par du code). On trouve aussi dans les ViewModels des évènements bien pratiques qui permettent de savoir quand on navigue vers la View ou quand on la quitte pour une autre View. On peut aussi choisir son conteneur d’IoC mais Mvvm Light et d’autres le permettent aussi. On peut ainsi choisir Autofac, Dryloc, NinJect, Ubity, etc, certains comme MEF ou StructureMap ne fonctionnant qu’avec WPF. En UWP on ne peut utiliser que AutoFac ou Unity. Sous les Xamarin.Forms le choix est donc plus vaste.

Chaque framework a son esprit. Je n’ai rien à dire sur ce point puisque c’est à chacun de faire son choix en fonction de ses gouts. En revanche on peut malgré tout faire un classement en fonction du nombre de services rendus et de la simplicité d’utilisation.

• Le niveau le plus bas, très simple et peu sophistiqué, ce sont les Xamarin.Forms elles-mêmes avec leur début d’implémentation MVVM qui évoluera certainement avec le temps. C’est facile à comprendre mais c’est loin de tout faire.
• Au niveau au dessus se trouve Mvvm Light. Light, léger, c’est sa devise. L’un des plus simple à comprendre mais il reste très limité par exemple dans les services de dialogue ou de navigation (je propose plusieurs solutions dans mon livre pour pallier ces problèmes d’ailleurs).
• Prism pour Xamarin.Forms arrive juste après. Déjà un peu plus complexe que Mvvm Light, mais plus riche.
• MvvmCross très complet et versatile mais assez fouillé.
• Caliburn vient derrière tous les autres. Nettement plus complexe (malgré le passage de Caliburn le vrai à Caliburn.Micro qui remplace le premier totalement aujourd’hui) mais beaucoup plus subtil.

Ce classement n’est pas un ordre de préférence. Par exemple bien qu’en dernier j’adore l’intelligence de Caliburn. Et bien que premier le système intégré à Xamarin.Forms n’est pour moi pas assez complet.

Prism et Mvvm Light / MvvmCross sont entre les deux. Avec l’avantage de la simplicité pour le second et quelques options intéressantes pour le premier. MvvmCross ayant à mon sens perdu un peu de son intérêt avec les Xamarin.Forms (par exemple le génial système de binding ajouté aux UI natives d’iOS et de Android ne sert à rien quand on a le binding de Xaml…).

Que choisir ?

Vraisemblablement vous opterez pour Mvvm Light ou Prism. Ceux qui ont pris leurs marques avec MvvmCross continueront sur leur lancée car c’est une excellente librairie aussi.

Téléchargement

Il suffit de chercher Prism dans les paquets Nuget et l’installation se fait aussi simplement que pour les autres librairies…

le site GitHub de Prism : https://github.com/PrismLibrary/Prism

Comme les autres Prism est en Open Source, sources que vous trouverez sur le site GitHub avec d’autres liens (docs et exemples notamment).

Conclusion

Vous l’aurez compris, ce qui m’intéresse le plus dans tous cela c’est la convergence cross-plateforme entreprise non pas par des francs-tireurs comme moi mais par Microsoft désormais…

Si tout cela me donne raison et justifie mes conseils depuis des années, ma satisfaction n’est pas mégalomane, j’ai eu raison c’est bien mais cela ne change pas la face du monde. Non si tout cela me fait plaisir c’est que depuis longtemps je pensais que l’avenir ne pouvait être que cross-plateforme car aucun OS ne pourrait plus représenter 100% du marché à lui tout seul et qu’il fallait s’attacher à créer le tooling pour gérer cette transformation de notre métier.

Ma satisfaction est ainsi de voir qu’aujourd’hui même une firme reine du tout fermé et du tout propriétaire comme Microsoft a su voir (enfin !) qu’il n’y aurait pas d’avenir sans ouverture. La multiplication des produits ou projets Open Source et cross-plateforme chez Microsoft est un tournant historique pour cette société. Elle se permet même sur ce point de dépasser les autres acteurs.

Ca faisait longtemps qu’on attendait une direction éclairée et ouverte de Microsoft, l’ère Nadella efface celle de Ballmer et du faux génie Sinofsky. Microsoft change, s’ouvre et se met en phase avec le monde qui change lui aussi. C’est très positif.

Prism pour les Xamarin.Forms, aujourd’hui lui-même produit Microsoft, n’est qu’un clou de plus la charpente de cette nouvelle bâtisse qui se construit.

Stay Tuned !