Conseils de performances MVVM pour les applications WinUI

Cette rubrique traite de certaines considérations relatives aux performances pour les applications WinUI liées à la MVVM, aux liaisons et à la composition d’affichage.

Modèle MVVM (Model-View-ViewModel)

Le modèle Modèle-Vue-ViewModel (MVVM) est courant dans de nombreuses applications WinUI. (MVVM est très similaire à la description de Fowler du modèle Modèle-Vue-Présentateur, mais il est adapté au langage XAML). Le problème avec le modèle MVVM est qu’il peut entraîner par inadvertance des applications qui ont trop de couches et trop d’allocations. Les motivations de MVVM sont celles-ci.

  • Séparation des préoccupations. Il est toujours utile de diviser un problème en éléments plus petits, et un modèle comme MVVM ou MVC est un moyen de diviser une application (ou même un seul contrôle) en éléments plus petits : la vue réelle, un modèle logique de la vue (modèle d’affichage) et la logique d’application indépendante de l’affichage (le modèle). En particulier, il est courant pour les concepteurs de posséder la vue à l’aide d’un outil, les développeurs de posséder le modèle avec un autre outil, et les intégrateurs de design de posséder la vue-modèle en utilisant les deux outils.
  • Tests unitaires. Vous pouvez procéder au test unitaire du modèle d’affichage (et par conséquent du modèle) indépendamment de l’affichage, sans vous appuyer sur la création des fenêtres, les saisies, etc. En conservant la vue petite, vous pouvez tester une grande partie de votre application sans avoir à créer une fenêtre.
  • Agilité pour les modifications apportées à l’expérience utilisateur. La vue a tendance à voir les modifications les plus fréquentes et les modifications les plus tardives, car l’expérience utilisateur est modifiée en fonction des commentaires des utilisateurs finaux. En gardant la vue séparée, ces modifications peuvent être effectuées plus rapidement et avec moins de perturbation pour l'application.

Il existe plusieurs définitions concrètes du modèle MVVM et des infrastructures tierces qui aident à l’implémenter. Mais l’adhésion stricte à n’importe quelle variante du modèle peut conduire à des applications avec beaucoup plus de surcharge que cela ne peut être justifié.

  • La liaison de données XAML (l’extension de balisage {Binding}) a été conçue en partie pour activer les modèles de modèle/vue. Mais {Binding} apporte avec elle un ensemble de travail non trivial et une surcharge du processeur. La création d’une {Binding} entraîne une série d’allocations, et la mise à jour d’une cible de liaison peut provoquer boxing et réflexion. Dans WinUI, ces problèmes sont résolus avec l’extension de balisage {x :Bind}, qui compile les liaisons au moment de la génération et est largement utilisée dans les exemples WinUI et les applications de production. Recommandation : utilisez {x :Bind}.
  • Dans MVVM, il est courant de connecter Button.Click au modèle d’affichage à l’aide d'une ICommand, par exemple les applications auxiliaires DelegateCommand ou RelayCommand courantes. Ces commandes sont des allocations supplémentaires, qui incluent cependant le détecteur d’événements CanExecuteChanged, s’ajoutent à la plage de travail et au temps de démarrage/navigation de la page. Recommandation: En guise d’alternative à l’utilisation de l’interface ICommand pratique, envisagez de placer des gestionnaires d’événements dans votre code-behind, de les attacher aux événements d’affichage et d’appeler une commande sur votre modèle d’affichage lorsque ces événements sont déclenchés. Vous devez également ajouter du code supplémentaire pour désactiver le bouton lorsque la commande n’est pas disponible.
  • Il est populaire dans MVVM pour créer une page avec toutes les configurations possibles de l’interface utilisateur, puis réduire les parties de l’arborescence en liant la propriété Visibility aux propriétés de la machine virtuelle. Cela s’ajoute inutilement au temps de démarrage et éventuellement à la plage de travail (car certaines parties de l’arborescence peuvent ne jamais devenir visibles). Recommandations : Utilisez l'attribut x :Load pour différer les parties inutiles de l’arborescence hors démarrage. En outre, créez des contrôles utilisateur distincts pour les différents modes de la page et utilisez le code-behind pour conserver uniquement les contrôles nécessaires chargés.

Contenu connexe

  • Last updated on