Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Thema werden einige Leistungsüberlegungen für WinUI-Apps im Zusammenhang mit MVVM, Bindungen und Ansichtskompositionen erläutert.
Das Model-View-ViewModel (MVVM)-Muster
Das Model-View-ViewModel (MVVM)-Muster ist in vielen WinUI-Apps weit verbreitet. (MVVM ähnelt der Beschreibung des Model-View-Presenter-Musters von Fowler, ist aber auf XAML zugeschnitten). Das Problem mit dem MVVM-Muster besteht darin, dass es versehentlich zu Apps führen kann, die zu viele Ebenen und zu viele Zuordnungen aufweisen. Die Motivationen für MVVM sind dies.
- Trennung von Bedenken. Es ist immer hilfreich, ein Problem in kleinere Teile aufzuteilen, und ein Muster wie MVVM oder MVC ist eine Möglichkeit, eine App (oder sogar ein einzelnes Steuerelement) in kleinere Teile zu unterteilen: die tatsächliche Ansicht, ein logisches Modell der Ansicht (Ansichtsmodell) und die ansichtsunabhängige App-Logik (das Modell). Dabei hat es sich bewährt, dass sich die Designer mit einem Tool um die Ansicht, die Entwickler mit einem anderen Tool um das Modell und die Designintegratoren mit beiden Tools um Ansicht und Modell kümmern.
- Komponententests. Sie können Komponententests des Ansichtsmodells (und folglich des Modells) unabhängig von der Ansicht durchführen, ohne dabei auf das Erstellen von Fenstern, die Steuerung von Eingaben usw. angewiesen zu sein. Indem Sie die Ansicht klein halten, können Sie einen großen Teil Ihrer App testen, ohne jemals ein Fenster erstellen zu müssen.
- Flexibilität bei Änderungen der Benutzererfahrung. In der Ansicht sind die am häufigsten und am spätesten durchgeführten Änderungen zu sehen, da die Benutzererfahrung basierend auf dem Feedback des Endbenutzers optimiert wird. Indem die Ansicht getrennt bleibt, können diese Änderungen schneller und mit weniger Umwälzungen an der App umgesetzt werden.
Es gibt mehrere konkrete Definitionen des MVVM-Musters und Drittanbieterframeworks, die sie implementieren. Die strikte Einhaltung jeglicher Variationen des Musters kann jedoch zu Apps mit viel mehr Aufwand führen, als gerechtfertigt sein kann.
- DIE XAML-Datenbindung (die {Binding}-Markuperweiterung) wurde teilweise entwickelt, um Modell-/Ansichtsmuster zu aktivieren. {Binding} ist jedoch mit einer hohen Arbeitssatz- und CPU-Auslastung verbunden. Die Erstellung einer Bindung führt zu einer Reihe von Zuordnungen, und die Aktualisierung eines Bindungsziels kann zu Reflektion und Boxing führen. In WinUI werden diese Probleme mit der {x:Bind}-Markuperweiterung behoben, die Bindungen zur Buildzeit kompiliert und in WinUI-Beispielen und Produktions-Apps häufig verwendet wird. Empfehlung: {x:Bind} verwenden.
- Bei MVVM wird „Button.Click“ gerne mithilfe eines gängigen ICommand-Hilfsbefehls wie „DelegateCommand“ oder „RelayCommand“ mit dem Ansichtsmodell verknüpft. Bei diesen Befehlen handelt es sich jedoch um zusätzliche Zuordnungen (einschließlich des CanExecuteChanged-Ereignislisteners), die den Arbeitssatz vergrößern und die Start-/Navigationszeiten für die Seite erhöhen. Empfehlung: Als Alternative zur Verwendung der praktischen ICommand-Schnittstelle sollten Sie Ereignishandler in CodeBehind einfügen, sie an die Ansichtsereignisse anfügen und einen Befehl in Ihrem Ansichtsmodell aufrufen, wenn diese Ereignisse ausgelöst werden. Außerdem müssen Sie zusätzlichen Code hinzufügen, um die Schaltfläche zu deaktivieren, wenn der Befehl nicht verfügbar ist.
- Es ist beliebt in MVVM, eine Seite mit allen möglichen Konfigurationen der Benutzeroberfläche zu erstellen und dann Teile der Struktur zu reduzieren, indem die Visibility-Eigenschaft an Eigenschaften in der VM gebunden wird. Dadurch erhöht sich unnötig die Startzeit, und auch der Arbeitssatz kann sich unnötig vergrößern, da einige Teile der Struktur möglicherweise gar nicht angezeigt werden. Empfehlungen: Verwenden Sie das x:Load-Attribut, um unnötige Teile der Struktur aus dem Startvorgang zu entfernen. Erstellen Sie außerdem separate Benutzersteuerelemente für die verschiedenen Modi der Seite, und verwenden Sie CodeBehind, um nur die erforderlichen Steuerelemente zu laden.
Verwandte Inhalte
Windows developer