Die ViewModels sind letztlich Wrapper auf die Daten. Das Binding zwischen
GUI und ViewModels wird über die LiveBindings durchgeführt.
Dann könnte man doch auch die
GUI direkt über die LB an die Daten binden?
Wenn ich die gängigen Programmierpattern (OCP, SRP, SOC usw.) stringent umsetzen will, dann führt kein Weg an einem MVVM-ähnlichen Konzept vorbei. Die Frage ist, ob ich das will, oder ob ich nicht doch pragmatisch das nicht ganz umsetze und manchmal ein wenig schludere.
Je komplexer ein System ist und je höher die Anforderung an Änderungen ist, desto eher sollte man die o.g. Konzepte 100% umsetzen. Hat man dagegen ein relativ einfaches bzw. normal komplexes System mit einigen wenigen Installationen, kann man ruhig etwas hemdsärmeliger an die Sache rangehen.
Ich betreue derzeit ein Bankensystem mit zig Installationen, wo nicht *wir* die Änderungen vorgeben und in neuen Releases und Versionen verteilen, sondern der Kunde quasi pausenlos Änderungen und Erweiterungen fordert. Uns fallen genau die Codestellen mächtig auf die Füße, die eben hemdsärmelig umgesetzt sind. Und ich bin heilfroh, u.a. MVVM eingeführt zu haben, denn an diesen Stellen sind wir flexibel wir nur irgendwas. Alle Klassen, die der Lead-Developer ohne OCP und SRP gebaut hat ("die Klasse macht alles automatisch") sind jetzt schon unbrauchbar. Letztendlich kommen wir nur dann mit den limitierten Resourcen über die Runden, wenn wir am Anfang unsere Hausarbeiten (MVVM usw) gemacht haben bzw hätten.
Ein anderes Uralt-Projekt ist etwas grober gestrickt (20 Jahre alt) und dort geht vieles nicht bzw. nur mit Codeklimmzügen, die heute schon ein Ende der Lebensdauer des Projekts einläuten (nach 20 Jahren ist mir das langsam auch wurscht).
Mit MVVM (z.B.) mag es heute ein Krampf sein, aber da man gezwungen ist, alles total sauber zu trennen wird man sich morgen freuen. Man muss es nur durchziehen. Bis zum letzten Buchstaben.
Einer der Architekten meinte:"Heute wird ein (Zeit-)Kredit aufgenommen, der sich morgen aber doppelt und dreifach zurückzahlt".