Brrrr, das ist doch kein MVVM, was Sir Rufo da geschrieben hat. Viel zu viel Code in der View.
Das kommt drauf an, was man unter MVVM versteht. Für mich gibt es (u.a.) zwei Sichtweisen die sich teilweise wiedersprechen.
1. Das Viewmodel abstrahiert die Daten und die Darstellung. Die View soll jederzeit austauschbar sein.
Beispiel: Es gibt ein Passwort und die Aktion Verbinden. Eine Logik besagt: die Aktion Verbinden darf nur ausgeführt werden, wenn das Passwort da ist.
2. Das Viewmodel repräsentiert die View, diese soll möglichst keine Logik enthalten.
Beispiel wie oben: Die Logik besagt: der Button für Verbinden ist nur Enabled, wenn in der Eingabe ein Text drin steht.
Bei 1 geht es eher um eine abstrakte Sichtweise, dagegen hat 2 eher die UI im Blick.
Anderes Beispiel:
Im Model hatten wir vier Auswahlmöglichkeiten. Es ging um die Plazierung einer gewissen Zone bezüglich der Oberfläche. Codiert ware das durch einen Aufzählungstyp.
Einerseits konnten wir das lösen mit einer IViewSelection im Viewmodel und in der UI einer Auswahlliste.
Andererseits war der Wunsch in der UI stattdessen vier Buttons zu haben (Radiobuttons waren auch eine Option)
Nach obiger Variante 2 würde man im Viewmodel dann vier IViewButtons machen und das Viewmodel schaut dass dann immer einer gedrückt ist.
Dagegen nach Variante 1 würde man bei der IViewSelection bleiben - es ist ja eine Auswahl - und dann in der UI die Logik implementieren.
Ich persönlich (und Stevie wphl auch) tendiere generell zu Variante 2. Da kann man mehr
unit testen.
Ich habe mir schon so das ein oder andere zum Thema MVVM und Delphi angesehen. Dabei ging die Bandbreite von „lächerlich“ bis zu „ganz niedlich“ verglichen mit WPF, UWP, Xamarin.Forms mal als Referenz für „sehr brauchbar“.
Oder kennt jemand eine Delphi-Variante die sich mit der Referenz ansatzweise messen könnte?
Unsere
Betonung liegt allerdings auf "ansatzweise"