Trennung von Logik und Oberfläche

[banaguitar]

Danke für Deine Erklärungen! Ich habe den Code formatiert und neu hochgeladen.
Es wäre sehr nett von Dir und natürlich auch von allen anderen, die Lust haben, meinen Quelltext zu verbessern.

[TigerLilly]

Willkommen in der Welt von MVVM, MVC etc.

"Trennung von Oberfläche und Logik" sagt sich so leicht. :-/
Gehört die Anzeige des Bilds wirklich zur Logik? Ich sehe die Entscheidung, welches Bild angezeigt werden soll, in der Logik, aber die tatsächliche Anzeige eher bei der Oberfläche. Sonst läuft man Gefahr, Kopfstände zu machen, nur um die Oberfläche von allem anderen zu trennen und landet bei einer Logik, die eh dauernd auf der Oberfläche herumfummelt, nur halt indirekt.

Vielleicht sind diese Links informativ:
https://www.google.com/search?q=delphi+mvvm

Und dieser hier ist auch gut:
https://www.youtube.com/watch?v=virHepvMetw

[banaguitar]

Danke, ich finde das auch nicht so einfach zu trennen...

[freimatz]

Hier nun mein Senf.
Also Trennung von UI und Logik finde ich recht einfach. UI ist in der .dfm und Logik in der .pas
Im Ernst: es kommt darauf an was man unter Logik versteht. Sebastian hat ja schon den Begriffe Oberflächenlogik und Geschäftslogik ins Spiel gebracht. Ich finde es wichtig alles zu trennen, wobei ich die Abtrennung der Geschäftslogik für wesentlich wichtiger halte.

Bei DDD wird aufgeteilt in UI, Domain und Infrastrukture.

Das was sich oben in Sample-Project.zip in der PosLayer.pas befindet ist etwas was ich der Oberflächenlogik zuordnen würde. Und das ist nach meiner Einschätzung schon recht gut. Das schlimmste für mich daran ist die Reihenfolge in bei den uses.

[Mavarik]

Aus einer PM an mich (Auszug)

Zitat von banaguitar:

Hey Frank,
...
Was würdest Du mir raten?
...

Ich dachte, dass meine Antwort ggf. für alle interessant ist:

MVC/MVP war mir nicht „genug“ – daher habe ich mich für meine Projekte zu MVVM entschieden.
Ich habe mich seht intensiv mit diesem Thema beschäftigt. Mein Fazit:

1.) Wir programmieren nicht in C# und daher halte ich mich nicht zu 100% an die MS-Regeln für MVVM, weil ich einfach sage, dass man es mit Delphi besser machen kann. (Oje, ich höre schon den Aufschrei)
2.) Das Schicht-Model von MVVM muss eingehalten werden, wenn nicht geht alles schief. Das bedeutet auch eine klare aufgaben Trennung. Die View – die im eigentlichen nicht unserem Form entspricht, da ein Form mehrere Views haben kann sollte möglichst keinen Code enthalten. Da wir aber für unsere Forms „echten Code“ haben und nicht nur eine X(A)ML, sehe ich es nicht ganz so strikt. Beispiel OnDrawCell eines StringGrids.
3.) Sicherlich kann es für einen View mehr als ein Viewmodel geben. Ist aber aus meiner Sicht eher selten. Stellt aber i.d.R. kein Problem dar.
4.) Das Model ist übrigens nicht die Datenbank-Schicht, auch wenn das in vielen Tutorials so dargestellt wird.
5.) Man braucht für MVVM kein Framework! Ohne Framework ist es einfach viel mehr Arbeit und kann schnell unübersichtlich werden. Ist aber machbar.
6.) Ein Framework für MVVM zu schreiben ist nicht ganz einfach – ich kann ein Lied davon singen. Leider haben mich andere Aufgaben davon abgehalten meine #D.MVVM in Version 3.0 fertig zu stellen, daher arbeite ich immer noch in den verschiedenen Projekten mit meiner Version 1.0, 2.0 und 2.5 – wobei der Ansatz der 3.0 einfach das ist was „jeder“ braucht. Btw. Ggf. kommt etwas direkt in der RTL von EMBT. (Dazu gab es eine Frage im letzten Onlinebefragung)
7.) Änderungen an der View erfolgen mit einem Aufruf von PropertyChange mehr nicht (so der MS Ansatz). Das ist natürlich Quark. Dem Aufruf kann ich problemlose ein Integer mitgeben (Level 1), damit die View nur das aktualisieren muss was gefordert ist. Ich kann aber auch ggf. mit dem Integer einen Pointer übermitteln um in einem Rutsch auch direkt Daten mit zu geben. (Level 2). Level 3 wäre dann direkt über ein Framework und einer Vermittlerschicht den Setter einer Komponente auf zu rufen.

Meine Empfehlung – Start Simple.

View first. Also erst die View (Form) erzeugen. Die View erhält dann ein ViewModel (Property Injection)– die View darf ja das Viewmodel kennen, nur nicht umgekehrt.
Die View gibt dann dem ViewModel eine Call-Back Procedure:

Procedure PropertyChange(aWhat : Integer); In dieser Procedure ist eine große Case für die Integer Werte:

Delphi-Quellcode:

Case aWhat of
  0 : begin // Refresh All
      end;
  1 : EdName.Text := fViewModel.Name; // .Name ist eine Property vom Viewmodel.
...
end; // of case

usw. Natürlich kann man auch einen Aufzählungstyp nehmen, aber das war mir immer zu viel Arbeit. ggf. Konstanen für die Aufruf.

Delphi-Quellcode:

Const
  cRefreshAll = 0;
  cName       = 1;

...

Delphi-Quellcode:

if fName <> aValue then
  begin
    fName := aValue;
    PropertyChange(cName);
  end;

Delphi-Quellcode:

{$SCOPEDENUMS ON}
Type
  TRefresh = (All,Nachname,Vorname,Strasse,Ort);

Für das Model geht es ähnlich.

Ich halte übrigens beim nächsten Kongress in Amsterdam mal wieder einen Vortrag zu MVVM.

Grüsse

Mavarik

[freimatz]

Meine Empfehlung an banaguitar: Verwende NICHT MVVM. Eine simple Trennung von UI und Logik recht am Anfang.

[Mavarik]

Zitat von freimatz:

Meine Empfehlung an banaguitar: Verwende NICHT MVVM. Eine simple Trennung von UI und Logik recht am Anfang.

Nicht zielführend wenn einer UI und Logik trennen möchte.

[TigerLilly]

Das Thema ist schon recht komplex + die "simple Trennung von UI und Logik" gibt es mE leider nicht. Man muss ein paar weitreichende Entscheidungen treffen, wenn man beginnt, da was umzusetzen.

Was für mich schwierig umzusetzen war:
- Wie kommen die Daten ins Formular und zurück?
- Wie findet Validierung statt und wie wird die ans Formular gemeldet?
- Wie verarbeite ich Daten, die es NUR im Formular gibt (Drucken, Excport etc)?