Sugerencias de rendimiento de MVVM para aplicaciones WinUI

En este tema se describen algunas consideraciones de rendimiento para las aplicaciones winUI relacionadas con MVVM, enlaces y composición de vistas.

El patrón Model-View-ViewModel (MVVM)

El patrón Model-View-ViewModel (MVVM) es común en muchas aplicaciones WinUI. (MVVM es muy similar a la descripción de Fowler del patrón Model-View-Presenter, pero se adapta a XAML). El problema con el patrón MVVM es que puede provocar accidentalmente aplicaciones que tienen demasiadas capas y demasiadas asignaciones. Las motivaciones de MVVM son estas.

• Separación de responsabilidades. Siempre resulta útil dividir un problema en partes más pequeñas y un patrón como MVVM o MVC es una manera de dividir una aplicación (o incluso un solo control) en partes más pequeñas: la vista real, un modelo lógico de la vista (modelo de vista) y la lógica de la aplicación independiente de la vista (el modelo). En concreto, es un flujo de trabajo popular tener diseñadores propietarios de la vista mediante una herramienta, los desarrolladores poseen el modelo mediante otra herramienta y los integradores de diseño poseen el modelo de vista mediante ambas herramientas.
• Pruebas unitarias. Puede probar unitariamente el modelo de vista (y, en consecuencia, el modelo) independientemente de la vista, por lo que no se basa en la creación de ventanas, la entrada de conducción, etc. Al mantener la vista pequeña, puedes probar una gran parte de la aplicación sin tener que crear una ventana.
• Agilidad para los cambios en la experiencia del usuario. La vista tiende a ver los cambios más frecuentes y los cambios más recientes, ya que la experiencia del usuario se modifica en función de los comentarios del usuario final. Al mantener la vista independiente, estos cambios se pueden incorporar más rápidamente y con menos alteraciones en la aplicación.

Hay varias definiciones concretas del patrón MVVM y marcos de terceros que ayudan a implementarlo. Pero el cumplimiento estricto de cualquier variación del patrón puede provocar que las aplicaciones tengan muchos más requisitos innecesarios de lo que se pueda justificar.

• El enlace de datos XAML (la extensión de marcado {Binding}) se diseñó en parte para habilitar los patrones de modelo y vista. Pero {Binding} aporta un conjunto de trabajo no trivial y una sobrecarga de CPU. La creación de un {Binding} provoca una serie de asignaciones, y la actualización de un objetivo del enlace puede causar reflexión y boxing. En WinUI, estos problemas se solucionan con la extensión de marcado {x:Bind}, que compila enlaces en tiempo de compilación y se usa ampliamente en ejemplos de WinUI y aplicaciones de producción. Recomendación: use {x:Bind}.
• Es popular en MVVM conectar Button.Click al modelo de vista mediante un ICommand, como los asistentes DelegateCommand o RelayCommand comunes. Sin embargo, esos comandos son asignaciones adicionales, incluido el agente de escucha de eventos CanExecuteChanged, la adición al conjunto de trabajo y la adición al tiempo de inicio o navegación de la página. Recomendación: Como alternativa al uso de la cómoda interfaz ICommand, considere la posibilidad de colocar controladores de eventos en el código subyacente, adjuntarlos a los eventos de vista y llamar a un comando en el modelo de vista cuando se generen esos eventos. También deberá agregar código adicional para deshabilitar el botón cuando el comando no esté disponible.
• Es popular en MVVM crear una página con todas las configuraciones posibles de la interfaz de usuario y, a continuación, contraer partes del árbol enlazando la propiedad Visibility a las propiedades de la máquina virtual. Esto agrega innecesariamente al tiempo de inicio y, posiblemente, al conjunto de trabajo (porque algunas partes del árbol nunca se pueden ver). Recomendaciones: Use la característica de atributo x:Load para aplazar partes innecesarias del árbol fuera del inicio. Además, cree controles de usuario independientes para los distintos modos de la página y use código subyacente para mantener solo los controles necesarios cargados.