Dicas de desempenho do MVVM para aplicativos WinUI

Este tópico discute algumas considerações de desempenho para aplicativos WinUI relacionados ao MVVM, associações e composição de exibição.

O padrão MVVM (Model-View-ViewModel)

O padrão MVVM (Model-View-ViewModel) é comum em muitos aplicativos WinUI. (O MVVM é muito semelhante à descrição de Fowler do padrão model-View-Presenter, mas é adaptado ao XAML). O problema com o padrão MVVM é que ele pode inadvertidamente levar a aplicativos que têm muitas camadas e muitas alocações. As motivações para o MVVM são essas.

• Separação de responsabilidades. É sempre útil dividir um problema em partes menores, e um padrão como MVVM ou MVC é uma maneira de dividir um aplicativo (ou até mesmo um único controle) em partes menores: a exibição real, um modelo lógico da exibição (view-model) e a lógica do aplicativo independente de exibição (o modelo). Em particular, é um fluxo de trabalho popular ter designers proprietários da exibição usando uma ferramenta, os desenvolvedores possuem o modelo usando outra ferramenta e integradores de design possuem o modelo de exibição usando ambas as ferramentas.
• Teste de unidade. Você pode testar a unidade do modelo de exibição (e, consequentemente, o modelo) independentemente do modo de exibição, não dependendo da criação de janelas, da entrada e assim por diante. Mantendo a exibição pequena, você pode testar uma grande parte do aplicativo sem precisar criar uma janela.
• Agilidade para que o usuário experimente alterações. A exibição tende a ver as alterações mais frequentes e as alterações mais tardias, pois a experiência do usuário é ajustada com base nos comentários do usuário final. Mantendo a exibição separada, essas alterações podem ser acomodadas mais rapidamente e com menos rotatividade para o aplicativo.

Há várias definições concretas do padrão MVVM e estruturas de terceiros que ajudam a implementá-lo. Mas a adesão estrita a qualquer variação do padrão pode levar a aplicativos com muito mais sobrecarga do que pode ser justificado.

• A associação de dados XAML (a extensão de marcação {Binding}) foi projetada em parte para habilitar padrões de modelo/exibição. Mas {Binding} traz um conjunto de trabalho não trivial e sobrecarga de CPU. Criar um {Binding} causa uma série de alocações e atualizar um alvo de associação pode causar reflexão e encaixotamento. No WinUI, esses problemas são resolvidos com a extensão de marcação {x:Bind}, que compila associações em tempo de build e é amplamente usada em exemplos de WinUI e aplicativos de produção. Recomendação: use {x:Bind}.
• É popular no MVVM conectar o Button.Click ao modelo de visualização usando um ICommand, tais como os auxiliares comuns DelegateCommand ou RelayCommand. No entanto, esses comandos são alocações extras, incluindo o ouvinte de eventos CanExecuteChanged, além de aumentar o conjunto de trabalho e o tempo de inicialização/navegação da página. Recomendação: Como alternativa ao uso da prática interface ICommand, considere colocar manipuladores de eventos em seu código subjacente, anexá-los aos eventos da visão e chamar um comando em seu view-model quando esses eventos forem gerados. Você também precisará adicionar código extra para desabilitar o Botão quando o comando não estiver disponível.
• É popular no MVVM criar uma página com todas as configurações possíveis da interface do usuário e recolher partes da árvore associando a propriedade Visibility às propriedades na VM. Isso aumenta desnecessariamente o tempo de inicialização e possivelmente o conjunto de trabalho (porque algumas partes da árvore podem nunca ficar visíveis). Recomendações: Use o recurso de atributo x:Load para adiar partes desnecessárias da árvore fora da inicialização. Além disso, crie controles de usuário separados para os diferentes modos da página e use code-behind para manter apenas os controles necessários carregados.