Trennung von GUI und Logik, wie geht ihr vor?

[Stevie]

Habt ihr übrigens gemerkt, dass die Binding Lösung auch die Typen Konvertierung von String in Int und wieder zurück übernimmt? ;) (mit nem kleinen Fehler im Demo seh ich gerade, negatives Ergebnis wird nicht richtig als signed Integer umgewandelt - fixed)

@divBy0: Beispiel müsste nach einem Update des svn repos nun fehlerfrei und erwartungsgemäß laufen.

[SebE]

Zitat:

Zitat von Stevie (Beitrag 1118177)

Habt ihr übrigens gemerkt, dass die Binding Lösung auch die Typen Konvertierung von String in Int und wieder zurück übernimmt? ;)

Du bist lustig!
Wie würde es denn anders funktionieren, besser: wo würde man es denn sonst noch einsetzen können?

Integer werden automatisch zu Zeichenketten, Zeichenketten werden automatisch zu Bezeichnern.
Das geht doch nicht mit rechten Dingen zu :twisted:

[ehX]

Ist es in der realen Welt nicht oft so, dass sich manche Porgrammierer gegenseitig lobhudeln, weil sie ach so tollen Code geschrieben haben und man auch noch in manchen Foren zerrissen wird, wenn man etwas nicht nach dem höchsten Gut der Programmierkunst programmiert hat, jedoch dann, im Gegensatz dazu, oft Programme mit "miesem" Code jahrelang überleben und erfolgreich sind? :-)

Warum ich das sage: Gutes Codedesign ist zwar generell löblich, jedoch nicht immer der Schlüssel zum Erfolg.
Oft trift sogar das Gegenteil zu: Die in kürzester Zeit hingewurschtelte "Quick'n dirty"-Lösung sichert einem oft genug den nächsten Auftrag vom gleichen Kunden :-D

Ich arbeite derzeit z.B. sehr viel in php mit dem Zend-Framework....mag sein, dass das "gutes" MVC ist..allerdings ist die unübersichtlichkeit aufgrund der MVC_Struktur so extrem, dass die Produktivität m.E. völlig flöten geht und ich das ganze in "bösem" prozeduralen Code oder auch OOP-Code, der nicht so extrem getrennt ist, schon 10x geschrieben hätte und der Kunde nicht so lange warten müsste.


Edit: Das ist nur meine Meinung! Um es nochmal zu verdeutlichen. :-)

[Stevie]

Zitat:

Zitat von SebE (Beitrag 1118179)

Zitat:

Zitat von Stevie (Beitrag 1118177)

Habt ihr übrigens gemerkt, dass die Binding Lösung auch die Typen Konvertierung von String in Int und wieder zurück übernimmt? ;)

Du bist lustig!
Wie würde es denn anders funktionieren, besser: wo würde man es denn sonst noch einsetzen können?

Integer werden automatisch zu Zeichenketten, Zeichenketten werden automatisch zu Bezeichnern.
Das geht doch nicht mit rechten Dingen zu :twisted:

Der Default Converter, den ich einsetze, kann fast alle simplen Datentypen. Hab ihm aber auch noch so kleine Nettigkeiten wie von Object auf Boolean (Assigned) verpasst. So dass man einfach mal abhängig davon, ob ein Item selektiert ist oder nicht Aktionen enablen/disablen oder visible machen kann.

Zitat:

Zitat von ehX (Beitrag 1118181)

Ist es in der realen Welt nicht oft so, dass sich manche Porgrammierer gegenseitig lobhudeln, weil sie ach so tollen Code geschrieben haben und man auch noch in manchen Foren zerrissen wird, wenn man etwas nicht nach dem höchsten Gut der Programmierkunst programmiert hat, jedoch dann, im Gegensatz dazu, oft Programme mit "miesem" Code jahrelang überleben und erfolgreich sind? :-)

Warum ich das sage: Gutes Codedesign ist zwar generell löblich, jedoch nicht immer der Schlüssel zum Erfolg.
Oft trift sogar das Gegenteil zu: Die in kürzester Zeit hingewurschtelte "Quick'n dirty"-Lösung sichert einem oft genug den nächsten Auftrag vom gleichen Kunden :-D

Ich arbeite derzeit z.B. sehr viel in php mit dem Zend-Framework....mag sein, dass das "gutes" MVC ist..allerdings ist die unübersichtlichkeit aufgrund der MVC_Struktur so extrem, dass die Produktivität m.E. völlig flöten geht und ich das ganze in "bösem" prozeduralen Code oder auch OOP-Code, der nicht so extrem getrennt ist, schon 10x geschrieben hätte und der Kunde nicht so lange warten müsste.


Edit: Das ist nur meine Meinung! Um es nochmal zu verdeutlichen. :-)

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.

Hat eigentlich schonmal jemand in diesem Thread das Wort Unittests fallen lassen? Jaja, es gibt so tolle Sachen wie TestComplete, aber bei einer Trennung kann ich mal ebend meine Business Logik durchtesten ohne dass ich darauf angewiesen bin, dass ich in Edit4 dies eingebe, auf Button1 klicke und in ComboBox2 was auswähle.

[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:

Zitat von ehX (Beitrag 1118185)

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:

Zitat von Stevie (Beitrag 1118186)

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:

Zitat von FredlFesl (Beitrag 1118190)

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:

Zitat von FredlFesl (Beitrag 1118190)

Quick'N Dirty wird mit Teeren'N Federn belohnt

Den muss ich mir merken ;)

[Hansa]

Zitat:

Zitat von Stevie (Beitrag 1118191)

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. :mrgreen: 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. :lol:

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