MVVM in der Realität

[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 von stahli:

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 von stahli:

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 von Stevie:

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 von Mavarik:

Zitat von Stevie:

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 von Mavarik:

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 von Stevie:

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...

[Stevie]

Zitat von Mavarik:

Zitat von Stevie:

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...

Ok, und wer hat diesen Notification Mechanismus initialisiert? Ich vermute in deiner View gibts irgendwo nen Batzen an Createbinding Aufrufen oder so? Lass dir doch nich alles aus der Nase ziehen, ich denke du machst schon MVVM, dann zeig doch mal nen Beispiel

[sh17]

schon genial gemacht. Ich habe auch lieber alles in der Code-Datei, anstatt alles im Formular reingebastelt. z.B. 3th-party Komponenten binde ich generell nicht in die IDE ein und erzeuge die lieber per Code.

@Stevie könnte man dein Beispiel auch um den VirtualStringTree erweitern?