Ich bin ja was MVVM angeht absoluter Neuling und habe mir in der Sache hier auch schon mehrfach Rat geholt.
Mittlerweile viel gelesen und auprobiert....
Es gibt viele Fragen die man für eine MVVM Aufteilng seines Projekts nicht aus der Beschreibung des MVVM Patterns entnehmen kann. Auf Vieles musste man mich erst stoßen...bzw. es wurde mal so am Rande erwähnt und ich habe mir dann zu den Schlagwörtern was ergoogelt.
Vom MFP Pattern her kenne ich solche Probleme nicht und es kann am Ende das selbe wie MVVM. In größeren Projekten habe ich dann halt zum Teil einen Haufen an Interfaces.
Der große Unterschied ist wohl, dass ich mir durch die Livebindings die Interfaces aus dem MVP spare.
Mein bisheriger Wissensstand beim Versuch das MVVM Pattern zu nutzen:
1. Die Livebindings erfordern handgeschrieben code. Irgendwie finde ich das halbgar.
2. Das MVVM Pattern existiert innerhalb eines Frameworks, so richtig selbstständig ist es nicht. Ganz anders als MVP das ja ohne Framework auskommt.
3. Das Framework ist eine sehr wichtige Sache. "Make or Buy" ist zu klären, denn Delphi liefert es nicht wirklich mit.
4. Wenn man MVVM mit nur einer View macht funktioniert es super. Wenn man mehrere benutzen möchte ist nicht ersichtlich wie die Navigation zwischen Views ins Pattern passt. Es gibt hier 2 Philosophien ViewModel-First und View-First die entscheidend dafür sind wie man die Navigation löst. daran hängt ein Rattenschwanz von Entwurfmustern wie z.B. Inversion of Control und das verwenden von Frameworks die IoC-Container mitbringen. Ich habe mich für VM-first und eine convention-over-configurtion Ansatz entschieden, was die Navigation angeht. Sprich wenn ich zu einem neuen ViewModel navigiere, spawned das "Framework" die zugehörige View (getclass ftw.). Ich weiß nicht ob das "richtiges(TM)" MVVM ist, aber nach dem ich jetzt mehrere Views und ViewModel gemacht habe, fühlt sich der code echt gut an. Ich habe den Ansatz unter dem Stichwort "Autotview" in einem VS-c#-Forum gefunden.
5. Fehler !!1 MVVM und Ansätze die die
RTTI stark in Anspruch nehmen scheinen mir gegenüber MVP anfälliger für Laufzeitfehler zu sein, weil die Abhängigkeiten nicht bereits zur Compilezeit geprüft werden können. Ich will ja eigentlich möglichst schon zur Compilezeit so viele Fehler wie möglich finden!
Gibt noch genug offene Fragen für mich...
Ich speichere z.B. zurzeit den Status der Anwendung in einem Session-Objekt welches ich dann persistiere, weil die Navigation auf VM-Ebene stattfindet und ich diese Informationen nicht umständlich von VM zu VM zu VM zu dessen Model-Object übertragen möchte. Mir gefällt das so, aber das Pattern sagt nichts dazu. Klar das Modelobject könnte ja auch für alle VMs das selbe sein. Das habe ich halt in die Session ausgelagert.
Ich nutze diesen thread einfach mal in der Hoffnung, dass mir jemand sagt ob ich soweit richtig liege.