MVVM - Model, View, ViewModel

Dialogschritte werden nach dem Muster Model-View-ViewModel (MVVM) organisiert. Dieses separiert Geschäfts- von Präsentationslogik, um eine wartbarere, testbarere und evolvierbarere Anwendung zu erhalten.

Das MVVM-Muster besteht aus drei Schichten: der View, dem ViewModel und dem Model. Insbesondere die Verwendung von Data Binding zwischen View und ViewModel sorgt für eine lose Kopplung und ist essenziell für dieses Muster. Die einzelnen Schichten haben folgende Verantwortlichkeit:

• View: Die View ist die Definition des dargestellten Dialogschritts. Dabei wird das Layout festgelegt und die Anbindung der ViewModels festgelegt. Wichtig ist, dass hier keine Geschäftslogik jedweder Form codiert ist. Auch das Aktivieren und Deaktivieren von UI-Elementen erfolgt nicht in der View, sondern per Data Binding. Im Code-Behind wird lediglich das Anstoßen von Logik (Commanding) derart codiert, das diese an das ViewModel delegiert (derzeit sind Commands noch nicht vollständig unterstützt).
• ViewModel: Das ViewModel ist ein Model, das spezifisch für eine View ausgeprägt ist und von daher nicht hinsichtlich der Wiederverwendung in unterschiedlichen Views getrimmt ist. Das ViewModel besitzt Eigenschaften, die an die UI gebunden werden, um so lose gekoppelt die View über Änderungen zu benachrichtigen. Das kann beispielsweise das Ändern eines berechneten Werts sein. Das ViewModel ist somit zuständig für logische Zustandsänderungen. Dabei darf das ViewModel keinerlei Kenntnis von der View haben! Als Schicht besitzt das ViewModel auch die Logik, um Commad-Logik auszuführen. Das kann beispielsweise das Laden von Daten über das Model sein.
• Model: Das Model kapselt die Geschäftslogik, die in Schleupen.CS wiederum in lokalem Code und primär in Services programmiert ist. Diese Datenzugriffsschicht kann Validierungslogik besitzen, die für die Nutzung der Services relevant ist und im ViewModel referenziert wird. Auch ViewModel-neutrale Geschäftslogik kann hier platziert werden. Modellobjekte können DataContracts (DTOs), aber auch POCOs sein. Das Model hat keine Kenntnis vom ViewModel.

Dieses Vorgehen der Separierung hat insbesondere folgende Vorteile: UnitTests und ComponentTests sind gemäß der Testpyramide leicht codierbar, da die View nicht benötigt wird. Da Code auch verständlicher wird, verbessert dies natürlich dann zwangsläufig auch die Wartbarkeit. Konzepitionell fungiert das ViewModell quasi als Adapter für Modellklassen, so dass Änderungen im Model einfacher umsetzbar und risikoloser sind.

In unserer Interpretation des Musters, verwenden wir folgende Bausteine, die auf der Metaebene folgende Beziehungen zueinander haben:

Dabei haben die Bausteine folgende Verantwortlichkeit:

• DialogStep: Ein DialogStep stellt die technische Klammer für mehrere Artefakte dar. Diese beinhaltet die XML-Datei zur Beschreibung der View und die damit verbundene Code-Behind-Datei sowie die Klassen des ViewModels.
• ViewModel: Klassen zur Visualisierung samt Logik. Zum einem beinhaltet dies beispielsweise das Main-Model und die zu bindenden ViewModel-Klassen wie bspw. BuchViewModel, das die Eigenschaften wie Titel, ISBN etc. zur Anzeige bringt. Zum anderen hat insbesondere das Main-Model ein Gateway etc. als Member, um Logik anzubinden, Daten zu laden etc.
• Gateway: Das Gateway dient dem Zugriff auf Services und kapselt den Assembler und den ServiceClient.
• Assembler: Klasse für die Übersetzung der Typen eines Service (Contracts) zu einem ViewModel und umgekehrt.
• Contracts: Die Contracts sind die DataContracts, MessageContracts eines Service.
• ServiceClient: Proxy-Klasse für den Service-Aufruf.

Bezüglich der Verteilung dieser Bausteine in Komponenten ist folgendes wichtig: auf der einen Seite wird die durch Services bereitgestellte Geschäftslogik in unterschiedlichen ViewModels angebunden, während auf der anderen Seite die ViewModels View-spezifisch ausgeprägt werden. Daher werden ServiceClient, Contracts und ggf. weitere Model-Klassen über eine Library bereitgestellt, nicht aber Assembler und Gateway.