MVVM in der Realität

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1304292)

Zitat:

Zitat von Stevie (Beitrag 1304286)

Denn in den letzten Jahren habe ich zu meinem Bedauern so einige Delphianer gesehen die an irgendwas MVVM geschrieben haben, was mal überhaupt kein MVVM ist.

Ab wann ist den ein System / Framework ein "echtes" MVVM und wann nicht?

Wenn es nach den Merkmalen von MVVM (ich liste die nun nich auf, Google kann jeder selber bedienen ;)) funktioniert und nicht nur irgendnen GUI-von-BL-Trenn-Gerät ist. Genauso wie ich nich einfach irgendwo MVC oder MVP dran schreiben kann, nur weils die Benutzeroberfläche vom restlichen Code trennt.

Und es geht dabei nicht um ein Framework sondern um die Methodik.

[QuickAndDirty]

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.

[Stevie]

Ich hab mal nen kleinen Prototypen zusammengeklatscht, wie ich mir ungefähr MVVM vorstelle - dabei hab ich mich von Knockout.js inspirieren lassen.

Fokus hab ich bei dem Prototypen auf das deklarative Databinding und ein bisschen Dependency Tracking gelegt. Alles was darüber hinaus geht, hab ich erstmal außen vor gelassen - für mich steht und fällt eine MVVM Lösung mit der einfachen Handhabung der V-VM Bindung.


https://bitbucket.org/sglienke/simplemvvm

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1304353)

Ich hab mal nen kleinen Prototypen zusammengeklatscht, wie ich mir ungefähr MVVM vorstelle - dabei hab ich mich von Knockout.js inspirieren lassen.

OK... Das sieht für mich alles aus als wäre es nicht wirklich mehr Delphi :stupid:

Es funktioniert - das ist schon mal gut...
Würdest Du nicht normalerweise den Code des ViewModels in einen andere Unit packen?

Abgesehen davon, das jeder klick auf das Formular den Code zerstört...

Gibt es irgendwo ein Tutorial was alles mit den Attributen geht...

Mavarik

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1304385)

Zitat:

Zitat von Stevie (Beitrag 1304353)

Ich hab mal nen kleinen Prototypen zusammengeklatscht, wie ich mir ungefähr MVVM vorstelle - dabei hab ich mich von Knockout.js inspirieren lassen.

OK... Das sieht für mich alles aus als wäre es nicht wirklich mehr Delphi :stupid:

Wenn du damit meinst, dass das Form nicht mit Eventhandlern vollgestopft ist, dann seh ich das mal als positiv an.

Zitat:

Zitat von Mavarik (Beitrag 1304385)

Es funktioniert - das ist schon mal gut...
Würdest Du nicht normalerweise den Code des ViewModels in einen andere Unit packen?

Na logisch, deshalb schrieb ich ja auch *zusammengeklatscht* :stupid:

Zitat:

Zitat von Mavarik (Beitrag 1304385)

Abgesehen davon, das jeder klick auf das Formular den Code zerstört...

Bei mir nicht, neue Komponenten oder Eventhandler können schön hinzugefügt werden ohne dass was kaputt geht (sowohl in XE, XE7 und XE8 keine Probleme).

[stahli]

@Stevie

Ich habe mir das Projekt mal angesehen.
Also dass das mit den Attributen so funktioniert ist schon beeindruckend. Auch das Ergebnis ist nicht schlecht.

Aber für meinen Geschmack bestehen da zum Einen sehr viele Abhängigkeiten und man muss genau wissen, was man tut.

Die Interfaces und anonymen Funktionen sind nichts für Laien sondern eher für Fortgeschrittene.
Wenn man an einer Stelle etwas nicht richtig macht, spielen die Gruppen nicht mehr zusammen.

Ich habe mal testweise das LastName-Edit in eine andere Groupbox verschoben und das Programm ließ sich nicht mehr kompilieren.
Zurücksetzen in die Originale Groupbox half auch nicht mehr.

(Ich wollte die Quellen nochmal neu auschecken, hatte aber dann Angst, dass ich meinen Murks statt dessen hochlade... und hab es lieber gelassen.)


Also mein Eindruck: Interessant, dass und wie es funktioniert hat.
Aber es setzt fortgeschrittene Fähigkeiten allgemeiner Art (Interfaces, Generics, Attribute, anonyme Methoden) und der Funktionalität des Frameworks voraus.


Würdest Du Dich Sir Rufo anschließen, dass es nicht wirklich eine Vereinfachung der Programmierung allgemein sondern eher eine Lösung zur Aufgabentrennung für mehrere Teams ist?

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1304405)

Wenn man an einer Stelle etwas nicht richtig macht, spielen die Gruppen nicht mehr zusammen.
Ich habe mal testweise das LastName-Edit in eine andere Groupbox verschoben und das Programm ließ sich nicht mehr kompilieren.

(Ich wollte die Quellen nochmal neu auschecken, hatte aber dann Angst, dass ich meinen Murks statt dessen hochlade... und hab es lieber gelassen.)

... ich werd doch nicht jedem Schreibzugriff auf mein Git repo geben ;)

Die Groupboxen haben rein gar nix mit der Funktionialität zu tun, sondern dienen der optischen Abgrenzung, ich hätt auch alles so auf die Form klatschen können.

Zitat:

Zitat von stahli (Beitrag 1304405)

Also mein Eindruck: Interessant, dass und wie es funktioniert hat.
Aber es setzt fortgeschrittene Fähigkeiten allgemeiner Art (Interfaces, Generics, Attribute, anonyme Methoden) und der Funktionalität des Frameworks voraus.

Naja, man sollte die eingesetzten Sprachtechniken schon beherrschen können - ich glaub, das ist nicht zu viel verlangt. Außerdem ist das ein Prototyp, wo ich mich um Fehlermeldungen, Validierung und dergleichen nicht geschert habe.

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1304407)

Naja, man sollte die eingesetzten Sprachtechniken schon beherrschen können - ich glaub, das ist nicht zu viel verlangt.

Ja, ja, ist aber schon hohe Schule, oder?

Die Bindings sind echt trickreich, aber ich finde das ist nicht wirklich lesbarer Code... Dann habe ich doch lieber ein bisschen mehr code im Formular und sehe, dass die Edit1... eine OnChange hat... und in der OnChange kann ich dann den Code reinbringen der alles nötige mit den Bindings macht.

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1304410)

Zitat:

Zitat von Stevie (Beitrag 1304407)

Naja, man sollte die eingesetzten Sprachtechniken schon beherrschen können - ich glaub, das ist nicht zu viel verlangt.

Ja, ja, ist aber schon hohe Schule, oder?

Keine Ahnung, für mich sind Generics, anonyme Methoden, RTTI und dergleichen so alltäglich wie nen TButton - obwohls die erst seit über ner halben Dekade gibt ;)

Zitat:

Zitat von Mavarik (Beitrag 1304410)

Die Bindings sind echt trickreich, aber ich finde das ist nicht wirklich lesbarer Code... Dann habe ich doch lieber ein bisschen mehr code im Formular und sehe, dass die Edit1... eine OnChange hat... und in der OnChange kann ich dann den Code reinbringen der alles nötige mit den Bindings macht.

Da trennen sich wohl unsere Meinungen, was lesbarer Code ist. Ich mag deklarativen Code, ich kann mit einem Blick sehen, welche Eigenschaft in dem edtFirstName angezeigt wird und ich muss mich nicht durch den OI hangeln, oder in der dfm rumsuchen, um zu sehen, wo irgendnen Binding verknüpft ist. Was würde denn in dem OnChange stehen? viewModel.FirstName := edtFirstName.Text? Oder firstNameBinding.Update oder sowas? Und wie kommen die Eigenschaften, die sich im VM geändert haben, wieder in die View?

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1304411)

Und wie kommen die Eigenschaften, die sich im VM geändert haben, wieder in die View?

Das VM lösst ein Property Change Multicast Event aus und alle Views die auf das Feld/Record/ViewGruppe hören aktualisieren sich...