Im View-Model kannst du auch deine Geschäftsdaten für die Anzeige transformieren oder zum Beispiel abgeleitete Eigenschaften implementieren. Man bindet beim View-Model ja nicht nur die Daten, sondern auch Eigenschaften wie z.B. Enabled eines Buttons. Die Entscheidung ob ein bestimmter Button enabled sein soll oder nicht, gehört nicht wirklich in die Geschäftslogik - vor allem nicht, wenn man PODOs verwendet. Ist die Eigenschaft im View-Model kann ich sie mit einem
Unit-Test überprüfen. Ich kann also im
Unit-Test Verhalten der
GUI testen.
Eigentlich hat man in einem ViewModel nicht den Enabled-Status eines Buttons drin, sondern für jede Aktion, die ausgeführt werden kann ein
CommandViewModel
mit den Minimal-Eigenschaften
sowie einer Methode
Execute
. Den Button (besser eine Action nehmen und die an den Button) verknüpft man nun einfach mit diesem
CommandViewModel
und schon ist alles gesagt, was gesagt werden muss.
Weiterhin habe ich im ViewModel nicht nur die Möglichkeit der Daten-Transformation, sondern auch das Bereitstellen von Lookup-Listen.
Delphi-Quellcode:
TPersonViewModel = class( ... )
public
// Benachrichtigung
property PropertyChanged; // Multicast-Event
// Lookup
propery GenderList;
// Daten-Felder
property Gender : Integer;
property FirstName : string;
property LastName : string;
end;
Das sind Sachen, die ich niemals in meinem Daten-Model haben möchte. Vor allem, weil das ViewModel sich auch um die Konsistenz-Prüfung kümmern kann, die darüber hinaus gehen, was das Daten-Modell prüfen kann/soll.
Wobei eine Daten-Instanz eher immutable (unveränderbar) sein sollte. Für das Auseinandernehmen und Zusammenbauen nimmt man einen Assembler und ein DTO (DataTransferObjekt). Das DTO hat jetzt die Möglichkeiten die Daten auf Konsistenz zu prüfen. Der Assembler baut aus dem DTO eine Daten-Instanz, wenn das DTO keine Fehler meldet. Das ViewModel nimmt eine Daten-Instanz mit dem Assembler auseinander in ein DTO und kann nun auch darin schreiben. Erst wenn das ViewModel und DTO keine Fehler mehr melden, dann gibt das ViewModel das Speichern-Kommando frei und baut mit dem Assembler eine neue Daten-Instanz zusammen, schickt diese an den Service, der sich um das Speichern kümmert. Konnte die Daten-Instanz erfolgreich vom Service gespeichert werden, schickt der Service eine Nachricht in die Runde, dass diese Daten-Instanz jetzt die aktuell gültige ist und alle ViewModels die es interessiert können diese jetzt übernehmen.
Und ja, das ist etwas ganz anderes als einfach einen Button ein Grid und eine Datenquelle auf ein Formular zu klatschen. Eigentlich bin ich doch schon fertig und geht auch viel schneller. Klar, wenn die Anwendung nur daraus besteht, ist ja auch alles gut, nur kenne ich wenige Anwendungen die damit auskommen. Da ist immer erheblich mehr und konsistent soll es auch sein. Und dann ist da noch der Multi-User-Fall. Da ändert ein anderer die Daten und nun, wie bringe ich meiner Anwendung bei diese Änderungen auch zu übernehmen?
Mit der oben skizzierten MVVM-Lösung wird der Service einfach dahingehend erweitert, dass er diese Änderung auch von aussen bekommt. Die Verteilung nach innen ist ja schon fertig