AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

MVVM in der Realität

Ein Thema von Union · begonnen am 8. Sep 2013 · letzter Beitrag vom 10. Jun 2015
Antwort Antwort
Seite 1 von 2  1 2      
mquadrat

Registriert seit: 13. Feb 2004
1.113 Beiträge
 
Delphi XE2 Professional
 
#1

AW: MVVM in der Realität

  Alt 9. Jun 2015, 09:04
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.
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: MVVM in der Realität

  Alt 9. Jun 2015, 11:49
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli ( 9. Jun 2015 um 11:58 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.052 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#3

AW: MVVM in der Realität

  Alt 9. Jun 2015, 12:32
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#4

AW: MVVM in der Realität

  Alt 9. Jun 2015, 12:50
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli ( 9. Jun 2015 um 13:05 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#5

AW: MVVM in der Realität

  Alt 9. Jun 2015, 13:00
@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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.052 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#6

AW: MVVM in der Realität

  Alt 9. Jun 2015, 13:38
@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.

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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie ( 9. Jun 2015 um 13:46 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#7

AW: MVVM in der Realität

  Alt 9. Jun 2015, 13:58
Diese Eigenschaft gibt es aber nicht in einer TCombobox
Das mit dem EmptyString war nicht direkt auf eine Combobox bezogen (obwohl das dort auch Sinn machen könnte, wenn man auch freie Eingaben ermöglichen will).

...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.
Ok, ich will das aber unbedingt. Es ist eben viel einfacher und schneller zu nutzen - jedenfalls wenn die IDE das gut unterstützt.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.165 Beiträge
 
Delphi 10.3 Rio
 
#8

AW: MVVM in der Realität

  Alt 9. Jun 2015, 14:31
ich will kein RAD-MVVM.
Ach nein... Komisch genau das will ich, daher wir von mir jede Komponente abgeleitet und die nötigen Einstellungen mit auf zu nehmen!
  Mit Zitat antworten Zitat
mquadrat

Registriert seit: 13. Feb 2004
1.113 Beiträge
 
Delphi XE2 Professional
 
#9

AW: MVVM in der Realität

  Alt 10. Jun 2015, 07:02
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?)
Ist ne Weile her (im Moment mache ich fast nur PHP Projekte). Wir haben eine Zwischenschicht, in der alle Bindings registriert werden. Ist die eine Seite des Bindings ein Control hängt sich die Zwischenschicht automatisch an das passende Event, das bei einer Änderung ausgeführt wird. Dazu gibt es je Control-Klasse einen Adapter, der automatisch gezogen wird. Bei einem PODO als Quelle muss man sowas ähnliches wie eine PropertyChangedNotification aus .NET abfeuern. Ich hatte auch mal Konstruktionen ausprobiert, die die nativen Typen kapseln und die Notification dann selbstständig auslösen. Fand ich aber immer ziemlich sperrig. Dazu kommt, dass in unseren Legacy-Anwendungen sowieso schon so eine Notification in jedem Setter steckt, um prüfen zu können, ob ein Wert sich geändert hat und abgespeichert werden muss.

EDIT: Wenn ich mal Zeit habe, kann ich auch mal den Code raussuchen. Ist nicht besonders hübsch, aber funktioniert für unsere Zwecke. Veröffentlichung war mal geplant. Aber da fehlt aktuell einfach die Zeit (und ein XE8)

@Stevie

Um das Problem des Null-Werts kommen wir bei uns herum, weil wir dafür immer den Index -1 ohne Text nehmen. nil wird bei uns also je nach Control immer zu einem Leerstring oder eben zum Index -1.

Geändert von mquadrat (10. Jun 2015 um 07:04 Uhr)
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#10

AW: MVVM in der Realität

  Alt 10. Jun 2015, 08:50
Das mit dem 'Null'-Wert ist so eine Sache.

Ich finde es vollkommen ok, wenn in einer Auswahl 'A,B,C' auch die Option 'None' vorhanden ist. Dann spare ich mir sowohl die Logik, ein 'Selected'-Element nullable zu machen, als auch die Problematik, was denn angezeigt wird, wenn noch nichts ausgewählt ist. Und ja: Ich gebe dem Anwender die Möglichkeit, 'None' wieder zu wählen. Es gibt ja auch Radiergummis. Nur valide wird das dann vermutlich nicht.

Diese Vorgehensweise (Auswahlliste läst alle angezeigten Möglichkeiten zu. Nicht mehr und nicht weniger) entspricht genau dem Verhalten einer Checkbox. Das kann man sich ja auch als Combo mit zwei bzw. drei Auswahlmöglichkeiten vorstellen. Und wenn das so ist, kann ich auch die 'grayed' Version wählen.

Wir verwenden MVVM in einem Reporting-Framework, wo die Report-Klasse die Filtermöglichkeiten (definiert durch die Query) vorgibt. Aus diesen wird ein VM und die UI dynamisch generiert, ähnlich den Reporting Services. Hier haben wir oft beide Fälle 'Noch kein Filter vorgegeben', oder 'wähle alle aus'. Das Pattern ist für beide gleich: Die Auswahlliste wird entsprechend erweitert.

Letztendlich ist das aber Ansichtssache, ob man -ebenso wie bei Textboxen- die Möglichkeit bietet, ein Eingabeformular auf den Grundzustand zu setzen oder nicht.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:46 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz