Trennung von GUI und Logik, wie geht ihr vor?

[SebE]

Zitat:

Mich persönlich hat bei dem MVC/MVP Modell immer gestört, dass man für meinen Geschmack zu viel Code erzeugt und trotzdem noch statische Abhängigkeiten hat

Das ist auch ansatzweise an deinem Beispiel sichtbar.

Das muss man wirklich zugeben. Die Menge an Code wächst enorm!
Bei großen Projekten wirkt sich das irgendwann nicht mehr so stark aus - und kann auch nicht umgangen werden.
Man sollte sich (bei großen Projekten) immer die Option offen halten, die GUI einfach auszutauschen (durch HTML-Oberfläche) oder zu erweitern (unterschiedliche Anzeigen gleichzeitig - sinnvoll: keine Ahnung; möglich: ja).

Mich stört beim "klassischen MVC", wie man es im WWW an jeder Ecke erklärt bekommt, dass die Trennung zwischen GUI und Model nicht stark genug ist (vor allem die Richtung View --> Model).
Beipsiel (durchgezogener unterer Pfeil):
http://de.wikipedia.org/wiki/Model_View_Controller

Zusätzlich verwende ich immer einen Presenter zwischen View (GUI) und Controller, denn es gibt Code, der weder in den Controller noch in die View (Formularcode) gehört. Weiterer Vorteil: mein Controller muss die konkrete GUI (oder deren Anzahl) nicht kennen.

---

Was ich für wichtig und keine leichte Aufgabe halte, ist die richtige Positionierung der "echten Verbindungen". Es muss ja eine bidirektionale Verbindung aufgebaut werden (View <--> Model).
- Wer kennt wen ab wann.
- Sollen Verbindungen verändert werden (Edit-Feld soll ein den Wert eines anderes Business-Objektes repräsentieren)?

[Luckie]

Zitat:

Zitat von Phoenix (Beitrag 1118100)

Zitat:

Zitat von divBy0 (Beitrag 1118094)

Ok, damit sieht dein ButtonOnClick so aus oder?

Delphi-Quellcode:

procedure TForm1.ButtonAdditionClick(Sender: TObject);
begin
  FAddition.Zahl1 := StrToIntDef(EditZahl1.Text, 0);
  FAddition.Zahl2 := StrToIntDef(EditZahl2.Text, 0);
  FAddition.Addition;
  LabelErgebnis.Caption := IntToStr(FAddition.Ergebnis);
end;

Dies sollte doch eigentlich auch vermieden werden, wegen Spaghetticode.

Nein, das sollte deshalb vermieden werden, weil das Form um himmels willen niemals im Leben nicht die Klasse TAddition kennen darf.

So würde ich das aber auch lösen. Wie sähe denn deine Lösung aus?

[shmia]

Der Ruf nach mehr Einfachheit und weniger Schreibarbeit ist aber schon berechtigt.
Ich vereinfache dazu meine Klassen auf das Minimum:

Delphi-Quellcode:

type
  TCalculator = class
  public
    procedure Addition;
    procedure Subtraktion;
    Zahl1: Integer;
    Zahl2: Integer;
    Ergebnis: Integer;
  end;

Wenn diese Hilfsklasse sowieso nur im Kontext des Formulars benützt wird, wozu dann diese schreibträchtigen Properties einbauen?
Im Gegenzug scheue ich mich aber auch nicht, relativ kleine und einfache (Hilfs-)Klassen in meinem Formular zu benützen.
Ich ersetze Properties durch public Variablen aber nur dann, wenn ich mir sicher bin, dass ich die Klasse nur hier an Ort und Stelle benötige.
Klassen, die weiter ins Programm reichen werden weiterhin "anständig" programmiert.

[Neumann]

Für diesen einfachen Fall zu umständlich.

Delphi-Quellcode:

type
   TAddition = class
   private
     
   public
     function Add(wert1,wert2:integer; var Ergebnis:integer):boolean;
     
   end;
Implemaentation

Function Taddition.Add;
begin
  Ergebnis:=wert1+wert2;
  result:=(wert1<>0) and (wert2<>0);
end;

Result zeigt dann ob was sinnloses gemacht wurde oder kann auf einen Konvertierungsfehler hinweisen.

Die Sache mit privaten Feldern, Methoden sowie Properties macht nur dann Sinn, wenn man Werte zwischenspeichen will.

[FredlFesl]

Weiss nich, mit MVC hab ich mich noch nie beschäftigt.

Ich würde einfach dafür sorgen, das mein Formular nur den Code (Logik, Bedingungen etc.) enthält, der für die GUI erforderlich ist (Prototyping).

Die Funktionalität erfolgt komplett in eigenen Klassen. Ziel ist es, das jede GUI-Aktion mit genau einem Methodenaufruf abgebildet werden kann.

Bisher habe ich sehr selten einen Fall gehabt, bei dem die Funktionsklassen zwischendurch der GUI Bescheid geben müssen, außer vielleicht bei einem Fortschrittsbalken. Wenn das der Fall sein sollte, arbeite ich mit dem Vistor-Pattern, Callbacks oder Notification-Events (meistens Letzteres). Und wenn ich faul bin (oder mit Threads arbeite) gerne auch mit Windows-Messages. Dann läuft die Anwendung zwar nie unter Linux, aber WTF.

Es ist etwas altbacken und pragmatisch, aber schlußendlich das Resultat jahrzehntelangen Programmierens mit dem Zweck des einigermaßen effektiven Geldverdienens auf freiberuflicher Basis. Da ich große Unternehmen zufrieden gestellt habe, kann es so falsch nicht gewesen sein.

Der große Künstler bin ich nicht, aber dafür bin ich sehr schnell und meine Anwendungen sind mittlerweile sehr robust und leicht wartbar. Da ich zudem die für mich wichtigsten Gedanken vom 'Clean Code' verfolge, bin ich eigentlich mit meinem Gegurke zufrieden.

Wenn ich mich mal dabei ertappe, rumzufrickeln, schlägt mir das spätestens bei der ersten fundamentalen Anforderungsänderung gnadenlos ins Gesicht.

Zitat:

Zitat von shmia (Beitrag 1118112)

Ich ersetze Properties durch public Variablen aber nur dann, wenn ich mir sicher bin, dass ich die Klasse nur hier an Ort und Stelle benötige.

Ich verwende diese Form für 'data transfer objects', sonst nicht.

[SebE]

Zitat:

Zitat von Luckie (Beitrag 1118111)

Zitat:

Zitat von Phoenix (Beitrag 1118100)

Zitat:

Zitat von divBy0 (Beitrag 1118094)

Ok, damit sieht dein ButtonOnClick so aus oder?

Delphi-Quellcode:

procedure TForm1.ButtonAdditionClick(Sender: TObject);
begin
  FAddition.Zahl1 := StrToIntDef(EditZahl1.Text, 0);
  FAddition.Zahl2 := StrToIntDef(EditZahl2.Text, 0);
  FAddition.Addition;
  LabelErgebnis.Caption := IntToStr(FAddition.Ergebnis);
end;

Dies sollte doch eigentlich auch vermieden werden, wegen Spaghetticode.

Nein, das sollte deshalb vermieden werden, weil das Form um himmels willen niemals im Leben nicht die Klasse TAddition kennen darf.

So würde ich das aber auch lösen. Wie sähe denn deine Lösung aus?

(fett durch mich)
Dann hast du aber die Aufgabe nicht gelöst, um die es hier geht.

Allgemein:
Eine saubere Trennung erreicht man nur durch Abstraktion. Dass diese Mehraufwand beim Schreiben verursacht, sollte hier nicht das Thema sein.

[Luckie]

Na ja, Getter und Setter sind schon sinnvoll. Dann kann man bei einer Division prüfen, ob nicht der Divisor 0 ist und entsprechend eine Exception werfen. Gut könnte man jetzt auch bei der Division machen. Aber das ist ja sowieso nur hypothetischer Code und es geht ja eigentlich um die Bindung der Klasse an die GUI.

@SebE: Wie würdest du denn das lösen? Bringt doch mal konkrete Lösungsvorschläge.

[SebE]

@Luckie:
Das steht doch in meinem ersten Beitrag auf Seite 1.

Ich mache eben aus 4 Zeilen Quellcode ~80 und verteile die dann auf 3 bis 4 Dateien.
Klingt schrecklich, aber wenn man ein Beispiel mit 500 Zeilen nimmt, wird der Overhead auch nicht mehr.
Bei dem wirklich winzigen Ausgangsprogramm würde ich auch dringlichst von MVC und Co abraten, da absolut überdimensioniert.
Aber wir wollen hier ja das Grundproblem im Allgemeinen lösen.

Wenn ich kurz abschweifen darf:
Wie würdet ihr folgendes lösen (Trennung spielt eine Rolle)?
Ihr habt eine Liste von gleichartigen Elementen, welche dynamisch erstellt werden und durch anklicken von Listeneinträgen (welche die Elemente für den User repräsentieren) ausgewählt werden. Dabei werden die Attribute der Elemente in visuellen Komponenten angezeigt (Edit, Combos, ...).

Also: beliebig mehrere Business-Objekte und nur eine Ein-/Ausgabe-Maske.
Welche zentrale Einheit übernimmt die Steuerung, was wann angezeigt wird.

EDIT: Vielleicht kann man sich vorstellen, dass wir das Ausgangsprogramm durch weitere Operationen (welche in der genannten Liste stehen) erweitern.
Wir haben sozusagen 4 Objekte (TAdditio, TSubtraction, TMultiplication, TDivision) aber nur 3 Edit-Felder.
Wir benötigen den Button nicht, da durch das Klicken in die Liste das Ergebnis sofort erechnet werden kann.

PS: "Sauber" in meinen Augen, wäre eine Lösung, welche den Operationslisten-SelectIndex nicht abfragt.

[Stevie]

Zitat:

Zitat von SebE (Beitrag 1118124)

Wenn ich kurz abschweifen darf:
Wie würdet ihr folgendes lösen (ob mit/ohne Trennung spielt erst einmal keine Rolle)?
Ihr habt eine Liste von gleichartigen Elementen, welche dynamisch erstellt werden und durch anklicken von Listeneinträgen (welche die Elemente für den User repräsentieren) ausgewählt werden. Dabei werden die Attribute der Elemente in visuellen Komponenten angezeigt (Edit, Combos, ...).

Die Properties des SelectedItem des Listen Controls an die anderen Controls binden. (siehe VirtualTreeviewSample oder Sample5 in meinem svn Repository)

Zitat:

Zitat von SebE (Beitrag 1118124)

EDIT: Vielleicht kann man sich vorstellen, dass wir das Ausgangsprogramm durch weitere Operationen (welche in der genannten Liste stehen) erweitern.
Wir haben sozusagen 4 Objekte (TAdditio, TSubtraction, TMultiplication, TDivision) aber nur 3 Edit-Felder.
Wir benötigen den Button nicht, da durch das Klicken in die Liste das Ergebnis sofort erechnet werden kann.

Entweder die entsprechenden Rechen routinen auf die Listen Items binden oder ein Objekt haben mit den 4 Operationen, welche abhängig vom ausgewählten Operator durchgeführt werden (das wär dann eher die ComboBox + Button Lösung)

[SebE]

Ja, dass ist eine gute Lösung.
Ich kenne diese aus C# in Verbindung mit WPF.
Geht das auch nativ? Ich bin leider schon einige Zeit aus Delphi raus.
Falls nicht: Hast du dennoch eine "hand-made-Lösung"?