Trennung von GUI und Logik, wie geht ihr vor?

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

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

[Medium]

Ohne negativ werten zu wollen (im Gegenteil): Ab und an frage ich mich ja dann doch, was es denn nun genau für einen Unterschied macht, ob ich bei Änderungen meiner Software meine Bindings nun im Quellcode, oder in einer separierten Deklarationsschicht umschreibe. Letztlich beides mit großer Wahrscheinlichkeit Textdateien, und "deployen" muss ich auch in beiden Fällen etwas. In der Quelle brauche ich lediglich meine Compilerumgebung statt Notepad - aber die sollte ich ja wohl tunlichst haben.
Nicht gleich hauen! Ich setze grad selbst radikale Abstraktionen in unserem Betrieb mit Nachdruck durch. Aber mir passiert es ja nun auch selbst gerne mal, dass ich vor lauter Streben nach Eleganz und Wohlgeformtheit die Praxis und den wirtschaftlichen Nutzen mal für eine Hand voll Stunden vergesse. Dabei selbst erwischt sag ich zu mir selbst: "Ach du verfluchter Theoretiker, das ist eine Maßlösung für einen Kunden, und es arbeiten max. 3 Leute daran, von denen 2 im selben Haus wohnen. Fertigwerden!" Es schubbelt aber doch ein wenig an der Berufsehre
Was is wohl sagen will ist: In Maßen, so lange es der (auch längerfristigen) Produktivität dient, alles prima. Man muss nur höllisch aufpassen, dass sich da kein Selbstzweck entwickelt, was ausgesprochen leicht passiert.

Im Alltagsgeschäft schaut es, bei mittelständischen Betrieben, zudem auch gerne mal so aus, dass Abstraktionen nach Bedarf entwickelt werden. Somit entsteht über Jahre ein Framework, dass immer mächtiger und hübscher wird - aber in vielen Iterationen/Versionen existiert, und da man anfangs fast nie alles bedenken kann was mal noch an Anforderungen kommt (einfach weil der Bedarf nie da war), man auch gerne zueinander inkompatible Stände hat. So dass das aktuelle Rahmenwerk nicht mehr zum Bearbeiten der ersten Hand voll Projekte auf dessen Basis dienen kann, weil zigfach geändert.
Sowas geht erst dann gut, wenn einem entweder die frühen Kunden die Zeit geben und bezahlen die man in ein derart umfangreiches und flexibles Framework investieren müsste (teilweise reden wir ja schon über Frameframeworks...), oder der Betrieb kann es sich leisten eigens dafür ein Team von Informatikern in Vollzeit abzustellen, die am eigentlichen Geschäftsfeld sonst eher wenig beteiligt sind. Unter einer mutig geschätzten 50-Mann-Softwareschmiede wohl eher seltener anzutreffen, und auch dort wird man anfangs RAD-like Code produzieren (weil so ein Framework ist ja nicht in 10h geplant und gebaut bzw. angepasst/gelernt), der entweder teuer nachträglich verhübscht werden muss, oder man ihn als Legacy-Fessel durch die Jahre buckelt, spätestens bis die Zielplatform am Ende ist.

Der wirtschaftlich nötige und sinnvolle Abstraktionsgrad ist, würde ich schätzen, einer der am schwersten abzuschätzenden Dinge in der Softwareentwicklung. Besonders weil seine Entwicklung ggf. selbst sehr viel Zeit bedarf, die man zwar auf die Gesamtheit aller je zu erstellenden Projekte positiv bilanzieren kann, sie aber schon vorab investieren muss, bevor man überhaupt auch nur ein Produkt verkaufen kann. Es sei denn, man verkauft Frameframeworks
Wenn es Kunden gäbe, die diese Dinge hinterblicken würden - DAMIT wäre uns wirklich sehr geholfen. Aber gebt mal einem Einkäufer diesen Thread hier zu lesen... Der schnallt doch ab! (Ausser er ist ungewöhnlich "open minded". Normal ist da reines Kurzfristigzahlenkleinhalten das einzige Programm im Hirncomputer.)

Sö, ich bin nun bereit eure Knüppel in Empfang zu nehmen

[ConstantGardener]

....keine Knüppel, +1

[Stevie]

Nun, es geht hier ja nicht um Übertreibungen sondern eigentlich um einige der einfachsten Software Prinzipien (z.B. SRP) Man kann das hier in diesem Thread beschriebene mit einfachen Mitteln realisieren, oder man kann es over engineeren. Natürlich kann man beim "klassischen Ansatz" bleiben, wenn es sich um ne 0815 Anwendung handelt und man dadurch nix gewinnt. Aber es mag auch Anwendungen geben, die über hunderttausende Zeilen Code gehen, mit hunderten von Forms und Frames. Gratulation, wer da noch bei dem klassischen Ansatz den Überblick behält. Ich kenne solchen Code nur zu gut, wo über Jahre immer neue Anforderungen in nem Form oder Frame implementiert wurden. Inzwischen sind das Monster geworden, die jeder einfach nur am liebsten in die Tonne kloppen und neu machen würde.

[stahli]

Zitat von Stevie:

Nun, es geht hier ja nicht um Übertreibungen sondern eigentlich um einige der einfachsten Software Prinzipien (z.B. SRP) Man kann das hier in diesem Thread beschriebene mit einfachen Mitteln realisieren, oder man kann es over engineeren. Natürlich kann man beim "klassischen Ansatz" bleiben, wenn es sich um ne 0815 Anwendung handelt und man dadurch nix gewinnt. Aber es mag auch Anwendungen geben, die über hunderttausende Zeilen Code gehen, mit hunderten von Forms und Frames. Gratulation, wer da noch bei dem klassischen Ansatz den Überblick behält. Ich kenne solchen Code nur zu gut, wo über Jahre immer neue Anforderungen in nem Form oder Frame implementiert wurden. Inzwischen sind das Monster geworden, die jeder einfach nur am liebsten in die Tonne kloppen und neu machen würde.

Da schließe ich mich an. Mein dienstliches Projekt (ich durfte ab 1993 2 Projekte für unsere Arbeit entwickeln, obwohl ich nicht als Programmierer angestellt bin) ist genau solch ein Fall. Daran habe ich über 15 Jahr immer wieder etwas dran erweitert.
Klar, würde nach Jahren ohnehin anders arbeiten. Aber große Korrekturen sind jetzt vor allem wegen der Vermixung von Programmlogig und GUI-Controls kaum noch möglich. Ich brauche lange, bis ich erahnen kann, was ich damals programmiert habe

Eine klare Trennung von Geschäftslogik und GUI würde dabei m.E. erheblich helfen. In Zukunft werde ich darauf achten.

Es stellen sich nur zwei Fragen:
- Wie komfortabel kann die die zwei Schichten verbinden? (Bisher geht das im Delphi ja nativ nicht so einfach.)
- Kann ich mir für mein aktuelles Projekt (durch geringen Mehraufwand am Anfang) insgesamt Arbeit sparen? (Das trifft für große und komplexe Projekte ganz bestimmt zu.)

Dann muss man darauf achten, dass die Programmlogik und die Formularanwendung jeweils komplett kompilierbar und funktionsfähig sind (wengleich man letzteres schwer vollständig testen kann), wenn der andere Part nicht existiert.

Um mal ein kleines, überschaubares Projekt zu erstellen, würde ich auf eine solche Trennung auch verzichten. Aber sobald das Projekt doch ausgebaut werden soll, dann unbedingt...

[Chemiker]

Hallo,

Zitat:

Eine klare Trennung von Geschäftslogik und GUI würde dabei m.E. erheblich helfen. In Zukunft werde ich darauf achten.

meiner Meinung nach wird das Project nicht zwangsläufig Übersichtlicher durch die Trennung. Und wie schon erwähnt, ist es leider so, dass bei Änderungen alle Ebenen in der Regel betroffen sind. Das mehr an Quellcode ist mit den heutigen Mittel die Delphi zur Verfügung stellt auch kein Problem. Dass man mit der Trennung die einzelnen Module besser Testen kann ist auch ok, aber man muss natürlich auch die Übergabe zusätzlich testen.

Bis bald Chemiker