Trennung von GUI und Logik, wie geht ihr vor?

[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

[neo4a]

Schönes Thema mit kontroversen Meinungen. Zur Ehrenrettung der "Hab-Ich-Schon-Immer-So-Gemacht"-Fraktion sollte vielleicht nicht unerwähnt bleiben, dass viele Lösungsansätze in Delphi erst seit relativ kurzer Zeit zur Verfügung stehen.

Meine Motivation, den Delphi-RAD-Ansatz (teilweise) zu verlassen, kommt aus der Einsicht, durchgängig testbaren Code zu entwickeln. M. Hevery (Chef-Tester von Google) hat die Vorteile von Data-Binding so zusammengefasst:

- MVC leidet naturgemäß an zirkulären Referenzen, die Probleme erzeugen und Unit-Testing sehr erschweren.
- Data-Binding kehrt den normalen Ablauf der Abhängigkeiten um, erlaubt es zirkuläre Referenzen zu vermeiden und weniger gekoppelte Systeme zu erzeugen.
- Data-Binding eliminiert viel Boiler-Plate-Code, der die Daten zwischen Model und View hin und her transportiert und macht unseren Code leichter lesbar und verständlicher.

Dieses Mantra hat er hier 2010 veröffentlicht und 1 Jahr später gibt es nun Delphi-Ansätze (aber nur für die letzten Versionen), wie man das Data-Binding nutzen kann.

N. Hodge (ehem. Delphi-Manager) hat in Zusammenhang mit Dependency-Injection hier gefordert:

Regel 1: Codiere immer mit/gegen Interfaces
Regel 2: Halte den Constructor einfach

Mit einem geeigneten Framework wie Emballo ("nimmt Interfaces den Schrecken") oder Stevies DSharp schreibt man nun Programme, die sich auf einmal "richtig" anfühlen. Auch wenn man es zurzeit noch nicht nutzt: Tests, Mockups, GUI-Austausch, verschiedene OS - das alles ist auf einmal greifbar nahe.

(Nicht nur HP's letzter Haken zeigt: Die IT-Zukunft wird durch die Software bestimmt. Und mir ist dabei wichtig, bei all den Wechseln gelassen bleiben zu können und bei Ziel-Plattform und -OS die zu bedienen, für die sich letztlich meine Kunden entscheiden.)