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.
Das ist leider so oft das Problem, dass manche nur ein Buzzword nehmen und dann was komplett anderes unter diesem Namen bauen oder verstehen.
ViewModel heißt genau so, weil es das Model für die View ist. Es stellt die Logik dar die in der UI vonstatten geht, damit man
- diese ohne UI Geklicke testen kann
- jemand, der geile UIs baut, das machen kann, ohne sich um Code zu kümmern (in Delphi nur bedingt möglich)
- man die UI je nach Zielplatform austauschen kann, ohne die Logik und Interaktion neu zu bauen (nur bedingt möglich, je nach Platform verhält sich die UI zu unterschiedlich, als dass man VMs wiederverwenden könnte)
Ein Kernaspekt von MVVM ist das binding zwischen UI/View und ViewModel und entsprechende Benachrichtigungsmechanismen. Das sollte man eigtl schon verstehen, wenn man sich nur das Bild auf Wikipedia anschaut. Wenn man anfängt statt dessen Code in die UI zu schreiben, die Bindings und Notifications zu ersetzen, dann ist das nunmal kein MVVM.
Und ja, die Jungs von Grijjy haben das verstanden - allerdings steht und fällt MVVM nutzen in Delphi mit der Komplexität und dem Tooling. Ein XAML, was mit direkt beim Kompilieren den Finger zeigt, weil ich was falsches gebunden habe ist weitaus hilfreicher als irgendwelche AVs oder sonstwas zu suchen, weil ich nen vertippser oder so im LiveBinding (oder einer anderen stringly typed Implementierung) habe.
Ich persönlich hab inzwischen das Thema MVVM in Delphi ad acta gelegt, weils einfach nicht rund wird. Für kleine Spielzeug Anwendungen ganz toll aber unbrauchbar, wenns größer wird.