Trennung von GUI und Logik, wie geht ihr vor?

[ehX]

Zitat:

Das mag in einem gewissen Grad und bei einem Einzelkämpfer oder einem kleinen Team auch gut funktionieren. Wird das Projekt aber mit der Zeit immer größer und umfangreicher und viele Personen sind damit beschäftigt, dann ist es einfach fast nicht mehr machbar mit der hingewurschtelten "Quick'n dirty" Lösung. Andere oder man selber muss den Code nach Jahren noch pflegen und erweitern.

Da gebe ich dir recht. Ich wollte damit eigentlich auch nur sagen, dass ein Programmierer sich vielleicht nicht von Anfang an unbedingt komplett darauf stützen muss, den "saubersten" Code zu schreiben, da das auch oft für die eigenen Ideen oder die Lösung im Kopf kontraproduktiv ist.
Optimieren und aufräumen muss man irgendwann, ja, aber nicht unbedingt immer gleich sofort

[Stevie]

Zitat von ehX:

Zitat:

Das mag in einem gewissen Grad und bei einem Einzelkämpfer oder einem kleinen Team auch gut funktionieren. Wird das Projekt aber mit der Zeit immer größer und umfangreicher und viele Personen sind damit beschäftigt, dann ist es einfach fast nicht mehr machbar mit der hingewurschtelten "Quick'n dirty" Lösung. Andere oder man selber muss den Code nach Jahren noch pflegen und erweitern.

Da gebe ich dir recht. Ich wollte damit eigentlich auch nur sagen, dass ein Programmierer sich vielleicht nicht von Anfang an unbedingt komplett darauf stützen muss, den "saubersten" Code zu schreiben, da das auch oft für die eigenen Ideen oder die Lösung im Kopf kontraproduktiv ist.
Optimieren und aufräumen muss man irgendwann, ja, aber nicht unbedingt immer gleich sofort

Manchmal kanns dann auch zu spät sein.... Wie war nochmal das Sprichwort: "Wehret den Anfängen!"

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

Zum Thema: Wer schonmal mit ExpressionBlend was gemacht hat, weiß, wie geil das sein kann, wenn man fein trennt zwischen GUI und Logik.

[FredlFesl]

Zitat von Stevie:

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 :

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 :

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 :

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 :

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.

[Hansa]

Zitat von Stevie:

wenn man voneinander trennen möchte.

Was geht nicht ??