Schon hat man das UI vom eigentlichen Code getrennt und kann das UI auch beliebig austauschen, bzw. für mehrere Plattformen anbieten.
Leider ist das nicht so einfach. Ein ViewModel modelliert ja auch (wie schon erwähnt) die Eingabemetapher, also Auswahllisten, Reaktion auf Eingaben ('OnChanged') usw. Es ist quasi (und daher auch der Name) ein Modell des Frontends (View), das der Benutzer sieht: Und das ist nun einmal auf den Bildschirm, das
OS, die Eingabegeräte und den Anwender zugeschnitten (hoffentlich jedenfalls).
Die ViewModels wurden entwickelt, um die Anforderungen an eine moderne (Web)-UI parallel umsetzen zu können und das Frontend bezüglich Layout jederzeit austauschen zu können. ViewModels eignen sich weniger, um Cross-Plattform zu entwickeln, wobei die 'Plattform' hier die Hardware (Bildschirm, Eingabegeräte usw) ist.
Die Codebasis wäre hier (und eigentlich überall) die Businesslogik. Jedes Businessoperation (z.B. Adressänderung) auf einem Businessobjekt (z.B. ein Kunde) wird in einer Klasse gekapselt. Diese Klasse ist dafür zuständig, im Maschinenraum die notwendigen Operationen durchzuführen, um die Adresse eines Kunden zu ändern. Dazu gehören insbesondere die Persistierung sowie Validierungen aber auch die Vorbereitung eines Kundendatensatzes. Diese Klasse ist damit ideal wartbar, höchst flexibel, leicht (und vollständig!) testbar und auch in einem Batchbetrieb zu verwenden. Wenn man irgendwann 1000000 Adressänderungen vornehmen muss (anderes Adressformat, andere PLZ sonstwas), freut man sich, eine derartige Businessoperation fertig (und einsatzbereit, da durch Unittests abgesichert!) in der Schublade zu haben.
Ein Viewmodel wird also für die Adressänderung nur die BO-Klasse instantiieren, die Eigenschaften der BO-Klasse an die eigenen Eigenschaften weiterleiten und Validierungen und Persistierung entsprechend übernehmen. Dabei ist das VM 100% an die entsprechende Oberfläche angepasst bzw. spezialisiert: Es muss wirklich nur diese eine (
VCL)-Form bedienen, im Extremfall auch mit genau dieser Auflösung (Auf einem 600x800 Bildschirm kann eine andere Metapher umgesetzt werden). Wenn die FMX-Form zufällig genauso aussieht, wie das
VCL-Pendant, gut. Muss es aber nicht. Man muss ja nur das Viewmodel anpassen.
Also: Im Ideallfall kommt ein Formular ganz ohne Code aus (die Bindings stehen in der
DFM oder wird über Attribute gesteuert). Das Binding kann auch im FormCreate/FormActivate stehen. Wenn man es nicht ganz auf die Spitze treiben will (pragmatischer Ansatz), kann man ein wenig Speziallogik auch in einem Formular unterbringen (konditionales Einfärben), aber die Tendenz muss sein: Keine Logik im Formular.
Nun kann man trefflich streiten: Wenn das VM doch eh nur für (normalerweise) genau ein Formular gebaut ist, wieso packt man dann nicht diese Logik gleich ins Formular rein? Ist doch weniger Arbeit. Stimmt, aber dieser Code ist so nicht so einfach testbar. Man trennt also VM von UI, um die VM besser und schneller testen zu können (=Unittests für VM). Funktioniert die VM, funktioniert auch das Formular so wie gewünscht.
Für die Button-Logik könnte man Actions (bzw. etwas, das an das WPF-ICommand-Pattern erinnert) nehmen: Dort wird die Kommando-Logik implementiert (diese sind dann auch plattformunabhängig). Der 'Speichere-die-Adressänderung'-Button bzw. das Kommando weiß am Besten, wann es ausführbar ist (Adresse geändert? Kunde vorhanden?). Und es weiß auch am besten, *wie* das Kommando umzusetzen ist (sind Userrechte abzufragen?* Muss geloggt werden? usw.). Dieses Kommando kann dann sowohl in der
VCL, als auch der
HTML, FMX usw. -Welt verwendet werden. Auch hier gilt: Wieso betreibt man den Schmuh? Antwort: Testbarkeit, Wiederverwendbarkeit. (* Die Sicherungsschicht kann auch in der Businesslogik untergebracht sein, aber eigentlich nur dann, wenn diese so existentiell ist, das selbst Programmierer die Operationen nicht ohne besondere Rechte verwenden sollen.)
Allgemein gesprochen kapselt man die Aktionen der Businessoperationen in Kommandos, abstrahieren die konkrete Ausführung und erweitern die Operation um einen Kontext (Kann das Kommando ausgeführt werden? Hint-Texte, Hilfestellungen, Icons, Benutzerführung usw.)
Es ist nun einmal mehr Arbeit, eine mächtige und flexible Applikation zu implementieren, die auf mehreren Plattformen läuft, als eine hinge-
RAD-zte. Diese Mehrarbeit ist jedoch eine Investition in die Zukunft, über die man sich im Klaren sein sollte: Entweder es lohnt sich (bzw. man geht das Risiko ein), oder nicht.