Um mal einen Überglick zu bekommen, haben wir hier die wesentlichen Unterschiede mal zusammengefasst. Was sich in PRISM bezüglich MVVM verändern bzw. entwickelt wird, muß man noch abwarten.
MVVM Foundation
- Unterstützt nur WPF
- ViewModel Basisklasse mit Runtime Property-Namen Checks
- Einfache ICommand Implementierungen: CommandViewModel, RelayCommand (auch bekannt als DelegateCommand)
- PropertyObserver: Überwacht PropertyChanges eines VM, Property wird als Lambda übergeben -> Compiletime Prüfung, ob Property existiert
- Mediator: Lose gekoppelte Kommunikation zwischen ViewModels, müssen nur Mediator kennen, aber nicht beteiligte VMs
- Keine Funktionen für Nebenläufigkeit
- Unterstützt nur WPF
- Einfache ViewModel und Command Basisklassen
- Über Atttached Behavior kriegt VM Lebenszyklen eines Views mit (Activated, Loaded etc.) ohne ihn kennen zu müssen
- NumericTextBoxBehavior
- Commands können im XAML an RoutedEvents gebunden werden
- Generischer Editable Wrapper für Model und ViewModel, hält States synchron. Auch eigene Implementierung von IEditableObject
- Validierung für Model-Eigenschaften mit definierbaren Regeln, Standard IDataErrorInfo Interface Implementierung
- WeakEvents
- Mediator Pattern (siehe MVVM Foundation)
- Unterstützt IoC Container (default: Unity), konfigurierbar via App.config
- Diverse Standardservices wie MessageBox, Save file etc. Unterstützen Unittests
- App.DoEvents() implementierung
- UI-Element Focus Helper
- Recht gute und umfangreiche Beispiele auf Codeproject
- Nebenläufigkeit:
- Dispatcher Helper für die Ausführung im UI Thread
- Definiert einige Extension Methoden für die Dispatcher Klasse (im Dispatcher, im Hintergrund, asynchron ausführen)
- Generische BackgroundTaskManager Klasse. Führt Code asynchron aus und ruft dann mit dem Ergebnis einen Completed Handler im UI Thread auf. Sehr einfache Verwendung
- Unterstützt WPF, Silverlight und Windows Phone 7
- Einfache ViewModel und Command Basisklassen
- Messenger (Mediator Pattern, siehe oben)
- Events to Command Binding
- Nebenläufigkeit: DispatcherHelper Klasse mit einer einfachen Hilfsmethode die Code im UI Dispatcher ausführt
- Unterstützt WPF und Silverlight
- Verwendet im XAML viel eigene Non-Standard Syntax und Konventionen. Mächtiger als Standard-Bindings, aber höherer Lernaufwand
- Konventionen, Benennungsschemen (Namespaces, Klassennamen etc.) sind API relevant für Autogenerierung/-finden von Views und ViewModels durchs Framework, Verhalten aber änderbar
- Viele Standard-Klassen implementieren keine spezifischen Schnittstellen, weisen sich nur durch Methoden aus
- Eigener DI Container, überschreibbar
- Bringt Standardimplementierungen von Commands und ViewModels mit
- Komplett eigene Application Management Klassen, großer Umfang
- Vermutlich viel Reflection um automatisch Klassen und Methoden zu finden, ist unter Umständen performancekritisch
- Actions, eine Art erweiterte Converter/Binding/Commanding/VM Mechanik fürs XAML
- ResolveExtension: Im XAML deklariert, holt Objekte aus dem DI Container
- Doku/Tutorials für den enormen Umfang auf der offiziellen Seite recht knapp
- Nebenläufigkeit:
- Threading Helper
- Methoden in Actions (ähnlich zu Command Methoden) können mit Attribut als asynchron markiert werden
- Gebundenes UI Element wird optional disabled während Code asynchron ausgeführt wird
- Ergebnis einer async. Action wird automatisch fürs DataBinding in den UI Thread überführt
- Es kann optional ein Completed Callback angegeben werden
Keine Kommentare:
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.