Trennung von GUI und Logik, wie geht ihr vor?

**FredlFesl**

Es muss jeder für sich entscheiden, ob er und sein Umfeld Nutzen davon hat, oder ob er "schludern" (nicht negativ gemeint) kann. Ich vergleich ein Programm oft mit einem Haus... und jeder kennt wohl den Begriff Pfusch am Bau. Aber bei Software meinen viele, dat sieht ja keiner, da kann ich ruhig alles zurechtpfuschen - "läuft ja".

Der Vergleich mit dem Hausbau, also Planung, Vorbereitung, Design, Ausführung ist sehr gut.

Ebenso, wie man ein Bauvorhaben totplanen kann oder sich bei Verwendung der aktuellsten und neuesten Technologie völlig verhaspelt, wird es in der praktischen Softwareentwicklung (betonung auf 'praktisch') eher so sein, das man nicht die allerneuesten Technologien verwenden wird, sondern die, die ihre Praxistauglichkeit über Jahre bewiesen haben.

Ebensowenig wie man rumfrickeln darf (Quick'N Dirty wird mit Teeren'N Federn belohnt), sollte man so lange refaktorisieren, bis man Preise für Schonheit im Code erhält, wenn man dabei Budget, Deadline und die Geduld des Kunden aus den Augen verliert.

Zwei Dinge sind wichtig (in meinen Augen):
Bei der Arbeit werden nur erprobte Techniken und Pattern verwendet, in der R&D-Zeit allerdings sollte man sich ständig weiterentwickeln.

**Stevie**

Zitat von FredlFesl:

Der Vergleich mit dem Hausbau, also Planung, Vorbereitung, Design, Ausführung ist sehr gut.

Ebenso, wie man ein Bauvorhaben totplanen kann oder sich bei Verwendung der aktuellsten und neuesten Technologie völlig verhaspelt, wird es in der praktischen Softwareentwicklung (betonung auf 'praktisch') eher so sein, das man nicht die allerneuesten Technologien verwenden wird, sondern die, die ihre Praxistauglichkeit über Jahre bewiesen haben.

Ich würde sowas, wie wir in diesem Thread behandeln eher mit nem Fertighaus vergleichen. Einzelne Teile werden getrennt von einander gebaut (GUI, Business Logik, Daten(klassen)) und vor Ort einfach zusammen gesteckt.

Zitat von FredlFesl:

Quick'N Dirty wird mit Teeren'N Federn belohnt

Den muss ich mir merken

**Hansa**

Zitat von Stevie:

Einzelne Teile werden getrennt von einander gebaut (GUI, Business Logik, Daten(klassen)) und vor Ort einfach zusammen gesteckt.

Ne, da wird nichts getrennt gebaut. Es wird ein zusammenhängender Bauplan gemacht und dann den Gegebenheiten angepasst. Siehe hier :

zusammenfalten · markieren

Delphi-Quellcode:

			procedure TfrmSuch.btnZurueckClick(Sender: TObject);

begin

  if not SuchDS.Bof then begin

    SuchDS.Prior;

    ZeigeDaten;

    btnWeiter.Enabled := true;

  end

  else begin

    showmessage ('keine vorhergehenden Daten vorhanden !');

    btnZurueck.SetFocus;

    btnZurueck.Enabled := false;

    btnWeiter.Enabled := true;

  end;

end;

Es geht dabei um eine Datensatz-Suche. An dieser Stelle ist SuchDS völlig unbekannt. ZeigeDaten sieht so aus :

markieren

Delphi-Quellcode:

			procedure TfrmSuch.ZeigeDaten;

begin

end;

Das ist also quasi Nullnummer.

Da geht es ja darum, etwas zu suchen. Manchmal ist man zu weit und muss zurück oder umgekehrt. Das bleibt immer gleich. Egal, um was es geht. Die GUI ist also schon da. Die Logik wird später eben besetzt. Man nennt das auch OOP.

**stahli**

Es geht ja aber gerade darum, das zu trennen.

Du kannst Deine gesamten Daten und Zustände in Deiner Datenebene verwalten. Ebenso die Methoden, die die Geschäftslogik darstellen.
Wenn Du Deine Datenebene als Objekt betrachtest, könntest Du z.B. über TFirma.MitarbeiterListe.BefördereMitarbeiter(5) irgendeine Aktion veranlassen.
Dadurch wird der Mitarbeiter gleich noch in das Chefzimmer verschoben und bekommt das doppelte Gehalt. Das wäre dann die Geschäftslogik

So, das Programm an sich funktioniert jetzt schon mal wunderbar.

Jetzt müssen wir noch ein Formular basteln, das die Daten anzeigt und einen Beförderungsknopf erhält.
Das ist auch schnell erledigt.

Nun fehlt noch die Verbindung der beiden Ebenen.
Mit DataBinding kann man eben zur Entwicklungszeit der ListBox die Mitarbeiterliste zuweisen (bestenfalls direkt im Objektinspektor per Aufklappliste) und dem Schalter die Beförderungsmethode.
Letzteres ist u.U. schwieriger, da ja manchmal bestimmte Parameter übergeben werden müssen. DAS muss man dann sicher per Code regeln.
Aber sonst muss es in der GUI nicht mehr viel Quelltext geben.

Also ich habe Blut geleckt!

EDIT:
Und wenn man mal auf die Idee kommt, das Projekt als Konsolenanwendung, als Webanwendung oder für FireMonkey

lauffähig zu machen, muss man grundsätzlich nur die GUI ersetzen. Alles weitere bleibt in der Datenebene unverändert. Nur der Zugriff von außen wird verändert.
Das ist eben bei einer "klassischen Delphi-Anwendung" so nicht möglich. Ebenso nicht spätere gravierende Umstrukturierungen.

**Stevie**

Zitat von Hansa:

Zitat von Stevie:

Einzelne Teile werden getrennt von einander gebaut (GUI, Business Logik, Daten(klassen)) und vor Ort einfach zusammen gesteckt.

Ne, da wird nichts getrennt gebaut. Es wird ein zusammenhängender Bauplan gemacht und dann den Gegebenheiten angepasst. Siehe hier :

zusammenfalten · markieren

Delphi-Quellcode:

			procedure TfrmSuch.btnZurueckClick(Sender: TObject);

begin

  if not SuchDS.Bof then begin

    SuchDS.Prior;

    ZeigeDaten;

    btnWeiter.Enabled := true;

  end

  else begin

    showmessage ('keine vorhergehenden Daten vorhanden !');

    btnZurueck.SetFocus;

    btnZurueck.Enabled := false;

    btnWeiter.Enabled := true;

  end;

end;

Es geht dabei um eine Datensatz-Suche. An dieser Stelle ist SuchDS völlig unbekannt. ZeigeDaten sieht so aus :

markieren

Delphi-Quellcode:

			procedure TfrmSuch.ZeigeDaten;

begin

end;

Das ist also quasi Nullnummer.

Da geht es ja darum, etwas zu suchen. Manchmal ist man zu weit und muss zurück oder umgekehrt. Das bleibt immer gleich. Egal, um was es geht. Die GUI ist also schon da. Die Logik wird später eben besetzt. Man nennt das auch OOP.

Sorry, aber sowas geht echt ma garnicht, wenn man voneinander trennen möchte.

**Luckie**

Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.

**SebE**

Zitat von Luckie:

Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.

(fett durch mich)

Im Allgemeinen gilt: je mehr Abstraktionen, desto flexibler die Anwendung (die Kommunikation).
Ob der Code dabei übersichtlich bleibt, ist fraglich.
Man kann auch Abstraktionen einführen, die wenig Sinn ergeben oder einfach nicht hilfreich sind.

Klar hat man irgendwo Bindungen. Diese sollten aber - wenn möglich - an "festen" Ort (Controller) plaziert werden und nicht dort, wo am ehesten Änderungen stattfinden (GUI, gefolgt vom Model).

Ein Muss ist auf jeden Fall, eine Abstraktion der GUI aus Sicht des Models, dieses darf die View nicht kennen.
Anders herum ist es vllt nicht immer notwendig, aber "schöner", wenn man eine zusätzliche Schicht hat (Controller).
Denken wir einmal an die Überarbeitung (Refactoring) unserer Business-Objekte (Schnittstellen "verschönern"): Hier wäre es gut, wenn man die GUI belassen kann, wie sie ist.

@Hansa:
Sorry, ich habe deinen Beitrag leider nicht verstanden (ich erkenne an deinem Code-Schnipsel weder OOP, noch wird mir eine Art Ironie ersichtlich).
Ich erkenne nur, dass hier nicht getrennt werden wollte.

**Stevie**

Zitat von Luckie:

Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.

Ich argumentiere ja für MVVM und da kennt das Form garnix, es hat Anzeige Controls, fertig. Wenn man Business Logik ohne den Ablauf über die GUI designed, kann man sie auch ohne die GUI Testen. Du kannst einfach testen, ob diese oder jene Eigenschaft so ist, wie du es erwartest, wenn du einen Wert setzt. Diese werden letztlich über die GUI präsentiert. Aber das Programm wäre auch komplett ohne Oberfläche lauffähig.

Zitat von Hansa:

Zitat von Stevie:

wenn man voneinander trennen möchte.

Was geht nicht ??

- Logik direkt ins Event kodiert.
- abhängig von der Logik werden wiederum Controls beeinflusst; zwar im kleinen Rahmen in diesem Beispiel, läuft trotzdem dem zuwider, was ich vor dem Quote schrieb.
- Feedback direkt über ShowMessage ausgegeben.

Diese Methode allein ist nicht unittestbar um zum Beispiel zu schauen, ob das mit dem nicht weiter zurück blättern klappt, wenn man schon vorne ist.

**QuickAndDirty**

[Edit]
sowas ähnliches was neo4a sagt... nur ohne die quellen...und nur binding mag ich nicht ganz so...
habe da in Javafx wirklich schlechte Erfahrungen mit gesammtelt.
[/Edit]

Zitat von Luckie:

Ich bin auch für eine Trennung von Daten und Oberfläche. Aber zu viele Ebene machen, meiner Meinung nach, das ganze zu unübersichtlich und führen die Trennung ad absurdum. Ich habe mal mit CakePHP gearbeitet, da gibt es auch dieses drei Schichten Model MVC (Model, View und Controller) das war hart an der Grenze. Deswegen würde ich das Formular ruhig die Additionsklasse kennen lassen. Noch eine Ebene dazwischen schieben, halte ich für überflüssig und für zu viel des Guten. Denn wo ist der Unterschied, ob das Formular jetzt die Additionsklasse kennt oder eine Schicht dazwischen? Irgendwann habe ich immer die Bindung von den Daten und der GUI.

Ich sehe das so, in einem MVC müssen die 3 Programmteile mit einander informationen austauschen ohne sich zu kennen.

Andererseits will ich nicht wirklich Zwischenebenen einbauen die jeweils 2 oder alles Teile Kennen und quasi eine Postkasten(Messagequeue) Funktion erfüllen.

Die einfachste möglichkeit sehe ich also darin IControler, IView und IModel zu definieren und jeweils gegenseitig zu registrieren.

Wichtig dabei ist das es NICHT ein IView, IControler und IModel gibt sondern das es durchaus möglich ist das ich weiter aufteile und ableite
IStammdatenView, IStammdatenControler, IStammdatenModel
IBewegungsdatenView, IBewegungsdatenControler, IBewegungsdatenModel

usw.

Klassen die diese Interfaces implemtieren lassen sich dann einfach einander als Interface Registrieren egal was am ende wirklich da bedient wird.

Es ist dann auch egal ob das Formular Spaghetticode enthält, weil für die Betrachtunge der Gesammtaufgabe braucht man sich nur an den Interfacedefinition orientieren und im Kleinen ist Spaghetti code ertragbar(verzicht auf binding).

Leider habe ich noch kein Programm gesehen das auf diese Art und weise entwickelt wurde...
außer eines...aber da wurde kein Interface benutzt sondern jede ebene jedes Anwendungsfalles mit einem Webservice dargestellt(StammdatenViewWebservice,StammdatenCon trolerWebservice,StammdatenModelWebservice) und SOAP legt die Zugriffsmöglichkeiten ja auch ziemlich gut fest ohne das man sich gegenseitig ganz genau kennen muss ähnlich wie Interface...man muss eben nur die Adresse wissen.

**divBy0**

Binding kommt ja erst mit XE2, DSharp von Stevie funktioniert erst ab D2010 so einigermaßen wegen den Generics. Ich hab jetzt noch nicht mit Google gesucht, aber gibt es denn weitere Binding-Komponenten?

Wenn ich das richtig verstehe konnte man bisher eigentlich nur mit MVC eine Trennung durchführen.

DSharp gefällt mir echt gut und ich experimentiere damit jetzt etwas rum.