MVVM in der Realität

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1304412)

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

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?

[mkinzler]

Stevie plant ja für dieses Jahr, die MVVM Implementierung in DSHARP zu aktualisieren/weiterentwickeln und es gibt hier ja auch Freiwillige im Forum, die ihm helfen wollen. ;)

[Stevie]

Zitat:

Zitat von sh17 (Beitrag 1304553)

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?

Ich hab noch eine andere Möglichkeit eingebaut für die, die Attribute nicht so mögen, indem man dann im Code einfach

Delphi-Quellcode:

Bind(...)

aufruft. Außerdem verhält sich die IDE etwas nickelig, wenn man ein Control löscht, denn dann bleibt das Attribut in der Luft hängen - doof.

Für den VST würde ich den DSharp TreeviewPresenter benutzen, dem man dann wunderbar eine Liste von Objekten geben kann und auf

Delphi-Quellcode:

SelectedItem

binden kann.

Zitat:

Zitat von mkinzler (Beitrag 1304565)

Stevie plant ja für dieses Jahr, die MVVM Implementierung in DSHARP zu aktualisieren/weiterentwickeln und es gibt hier ja auch Freiwillige im Forum, die ihm helfen wollen. ;)

Genau deshalb hab ich den Prototypen geschrieben, um schonmal Feedback zu sammeln. ;)

[mquadrat]

Schaut auf jeden Fall eleganter aus, als das, was ich gebaut habe. Die Attribute finde ich gut, aber das Problem wird halt sein, dass die IDE im Designer damit nicht sonderlich gut klar kommen wird. Wir verwenden die meiste Zeit Konventionen als Binding. Sprich hat das Control den gleichen Namen wie eine Property des BindingContext, dann binde da automatisch dran. Und je nachdem was es für ein Control ist, wird halt gegen eine andere Standard-Eigenschaft gebunden.

Was ich noch anregen würde, wäre den Zugriff auf die Werte gegen die gebunden wird zu abstrahieren. In unseren Legacy-Anwendungen haben wir Getter/Setter statt Properties. Ich müsste also eine Zwischenschicht einziehen können, die wahlweise mit einer Instanz, die aus Properties liest oder eben mit einer, die die Getter/Setter verwendet, arbeiten kann.

[stahli]

Der Weg erscheint mir ehrlich gesagt (potenziell) stabiler und einfacher als der von Stevie.

Wenn man ein Control löscht gibt es eben nichts mehr, was dort irgendwas daran zu binden versucht. Im Fall von Attributen scheint es ja Probleme zu geben und wenn man Bindings im Quelltext definiert ist die GUI ja auch vom Quelltext abhängig.

Kannst Du mal kurz skizzieren, wie Ihr die Aktualisierungswege in beiden Richtungen realisiert?
- Eingabe im Edit ändert den Wert in der Datenschicht (evtl. nach Validierung)
- Änderung von Daten durch Logik informiert Edit zwecks Neuzeichnung (müsst Ihr da z.B. Nachrichten in Settern versenden?)

Die Frage ist ja entscheidend, wie komfortabel das Framework zu nutzen ist.

So wie ich Dich bisher verstanden habe liegt Eure Lösung etwa auf meiner Schiene. Allerdings wäre natürlich eine Bindung an variable Controls und Controleigenschaften sinnvoll.

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1304670)

Der Weg erscheint mir ehrlich gesagt (potenziell) stabiler und einfacher als der von Stevie.

Attribute sind einer von vielen Wegen. Du kannst auch in deinem FormCreate die ganzen Bind(...) Aufrufe tätigen wie ich oben doch bereits schrieb.

Und CoC birgt andere Hürden. Zum Beispiel wüsst ich gerne, wie man über die Benamung einer Combobox diese mit Objekten und deren Namen plus einem Caption ('Bitte wählen sie was aus') befüllt wenn im VM nur eine Property mit einer Liste dieser Items ist. Wo hinterleg ich die Info, dass der Anzeigetext der Name ist und ich dieses Zusatzelement als erstes habe, was "keine Auswahl" repräsentiert. Ins VM gehört diese Info mMn nämlich nicht.

[stahli]

Aus meiner Sicht gehören diese Infos (Vorgaben) optimaler Weise direkt in die Controleigenschaften. Also z.B. eine Eigenschaft: EmptyString = "hier Text eingeben".

Für andere Zwecke kann man z.B. global Zuordnungslisten ablegen, die das Framework dann benutzen kann.
Z.B. für einen Aufzählungstyp TSex = (sxMale, sxFemale) könnte man global Strings hinterlegen:
NIL="bitte wählen Sie aus"
sxMale="männlich'
sxFemale="weiblich"

Dann kann das Framework erkennen was welche Texte es z.B. in einer Combobox anbieten muss, wenn sie an ein Feld vom Typ TSex gebunden ist.
Auch das Schreiben des ausgewählten Wertes kann das Framework dann über die hinterlegte Tabelle vornehmen.

Mit den Standardcontrols ist das natürlich schwer zu realisieren. Aber man kann sich diese ganzen ViewModels, Controller und Registrierungen sparen.

[Sir Rufo]

@Stevie

Wenn es eine Auswahlmöglichkeit gibt, die besagt, dass aktuell nichts ausgewählt ist, dann gibt das das ViewModel vor. Die View stellt nur das Control und die statische Beschriftung.

[Stevie]

Zitat:

Zitat von Sir Rufo (Beitrag 1304685)

@Stevie

Wenn es eine Auswahlmöglichkeit gibt, die besagt, dass aktuell nichts ausgewählt ist, dann gibt das das ViewModel vor. Die View stellt nur das Control und die statische Beschriftung.

Würdest du dann nil (oder ein Null-Object) in die Liste der Möglichkeiten aufnehmen? Find ich eher suboptimal. Dass nil eine Auswahlmöglichkeit ist, ergibt sich ja aus der "ausgewähltes Element" Eigenschaft.

Zitat:

Zitat von stahli (Beitrag 1304684)

Aus meiner Sicht gehören diese Infos (Vorgaben) optimaler Weise direkt in die Controleigenschaften. Also z.B. eine Eigenschaft: EmptyString = "hier Text eingeben".

Diese Eigenschaft gibt es aber nicht in einer TCombobox - außerdem wäre ich dann wieder im OI unterwegs, um irgendwelche Binding relevanten Dinge einzustellen. Und das wollt ich eher vermeiden bei dem Ansatz - ich will kein RAD-MVVM.