Ja "unmissverständlich" wird gesagt, dass das VM die Daten aus dem Model auch ggf. Interpretiert und ggf. anders an die View weiter gibt.
Also hat das VM ggf. auch intern eine eigenen Datenbestand für die View...
Der Kernpunkt ist, dass das VM die Kontrolle darüber hat, was in beide Richtungen fließt.
Lass uns nochmal kurz definieren, was bei MVVM Model und ViewModel sind.
Bei dem Model kann es sich um eine simple TCustomer Klasse mit 5 string Eigenschaften und sonst nix handeln oder um eine TSpeicherDruckUndSchickEmailsKlump Klasse mit siebenundöffzig Methoden.
Das ViewModel abstrahiert die Funktionialität des Models, die in der View benutzt wird und bereitet sie entsprechend auf. Wenn ich von den 5 Eigenschaften nur 3 Anzeige, dann gibt es möglicherweise nur genau diese 3 Eigenschaften im ViewModel (caching, edit, save, cancel etc mal außen vor gelassen). Wenn es nun so sein soll, dass ich die 3. Eigenschaft nur befüllen kann, wenn die 2 anderen Eigenschaften bestimmte Werte haben, dann gibt es eine "Eigenschaft3Enabled" Eigenschaft im ViewModel, welche an das entsprechende UI Control für diese Eigenschaft gebunden wird und durch Änderungen der anderen beiden Eigenschaften im ViewModel beeinflusst wird. Hierbei sorgen die Bindings und ein entsprechende Benachrichtigungssystem für das Updaten in beide Richtungen:
In der UI in den Controls für Eigenschaft 1 oder 2 was geändert -> binding aktualisiert das VM -> "Eigenschaft3Enabled" wird ggf verändert -> "Eigenschaft3Enabled hat sich geändert" Notification triggert -> binding bekommt das mit -> UI Control für Eigenschaft 3 wird entsprechend an oder ausgeschaltet
D.h. irgendwelche Businesslogik wird in den meisten Fällen nichtmal im ViewModel gehandhabt sondern im Model. Das ViewModel ist quasi nur die Abstraktion der UI. Dort steht drin, dass bei der Konstellation XY die CheckBox Z angezeigt wird oder nicht.
Und genau jetzt ergibt sich oft die Tücke, dass gewisse Dinge dann doch irgendwie Businesslogik sind und Teil des Models sind (komplexe Regel validierung, etc), aber doch bitte in der UI reflektiert werden soll. Das muss dann immer komplett durch das ViewModel hin und zurück fließen - guckstu
https://stackoverflow.com/questions/...or-a-viewmodel
Das heißt also, dass hier das VM schon mehr Teil der UI als der Businesslogik ist - schaust du hier:
https://stackoverflow.com/questions/...ttern-and-mvvm
Wenn du dir den 2. Grund anschaust, warum MVVM so toll ist/sein soll, dann wird klar, warum das in Delphi in dieser Form so schnell zusammen fällt, da gibs kein Blend. Rapid Prototyping funktioniert bei uns ein bisschen anders (TPrototypeBindSource, TClientDataSet etc).