Trennung von GUI und Logik, wie geht ihr vor?

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

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

[Luckie]

Zitat von divBy0:

Binding kommt ja erst mit XE2, DSharp von Stevie funktioniert erst ab D2010 so einigermaßen wegen den Generics.

Ach deswegen habe ich seine Lösung nicht verstanden. Ich habe noch 2006 und noch nie mit Generics was am Hut gehabt.

[SebE]

Zitat:

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

Ich würde es so sagen: MVC ist das intuitivste, machen kannst du das, wie es dir beliebt.
FÜr mich ist MVC mehr ein Gedanke, die Umsetzung im Detail entspricht auch nicht dem "Standard" (den es ja so garnicht gibt).
Entwurfsmuster sind ja nur grobe Ideen (die Philosophie einer Problemlösung)

[stahli]

@DivBy0 + Luckie
Die Generics sind dabei nicht so maßgeblich, aber die neue RTTI ist eine Voraussetzung für die Bindung von außen.
Das anzubindende Objekt muss z.B. untersucht werden, ob das anzuzeigende property "Text" vorhanden ist.
Das ist mit der älteren RTTI in dem Umfang nicht möglich.

[Stevie]

Zitat von divBy0:

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

Freut mich, bei Fragen, Anregungen oder Bugs, einfach ne pm oder email an mich

Zitat von 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?

Nicht in dem Umfang und mit den Features, die ich implementiert habe, welche Zielsetzung ich verfolge, habe ich in einem meiner ersten Blogposts erläutert. Es gibt einige Mechanismen auch in anderen Komponenten (die data sensitiven Controls, wo man z.B. den Fieldname setzt). Ich kann auch schon in Delphi 7 und früher 2 Objekte verbinden, und sie miteinander kommunizieren lassen, ohne, dass sie sich gegenseitig kennen müssen. Meine Grenzen sind aber nunmal da, wo die Sprachunterstützung aufhört. Der größte Kritikpunkt wurde ja schon genannt, es ist string basiert, da es keinen language/compiler support für property binding gibt. Und die Notifications bei der Änderung einer Property muss auch selber implementiert werden, damit die angeschlossenen Bindings darüber informiert werden und die Gegenseite aktualisieren. Beides Dinge die meiner Meinung nach einfach zu implementieren wären und einen großen Schritt auch für RAD bedeuten würden.

Es gibt einige entscheidende Gründe, warum die derzeitige Lösung ab 2010 funktioniert - ich glaube aber alles davon könnte mit Abstrichen hier und da anders implementiert werden, um es auch in alten Delphi Versionen lauffähig zu machen:

• Multicast Events - die Implementierung, die ich gewählt habe, macht von Generics Gebrauch, so, dass ich aus jedem beliebigen Event typ (z.B. TNotifyEvent) ein Multicast Event machen kann. Würde aber auch ohne gehen, dann müsste man die konkreten Typen halt auscodieren, ähnlich wie man früher typisierte Objektlisten gebaut hat.
• RTTI - Eigenschaften von den einfachsten Objekten sollen bindable sein, geht nur mit der RTTI ab 2010, bei der alten ist man auf published Properties und TPersistent Derivate angewiesen.
• verbesserte Designtime Unterstützung - irgendwann zwischen Delphi 7 und Delphi 2009 wurden einige Erweiterungen für den OI gemacht, indem man selber dort Properties registrieren kann, die aber eigentlich garnicht Teil den Objekts sind - die gebrauche ich, um den dafür registrierten Controls die DataBinding Eigentschaft zu verpassen, sobald eine TBindingGroup auf dem Form oder Frame liegt - darauf müsste man verzichten, aber man kann ja immernoch über die BindingGroup selber Bindings anlegen.

[Phoenix]

Zitat von bernerbaer:

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. [...] Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Du arbeitest wahrscheinlich nicht an größeren Projekten. Bei einem kleinen Projekt, an dem man alleine arbeitet, mag das pragmatisch und effizient sein. In einem größeren Projekt, wo Teams >= 10 Personen arbeiten ist z.B. gerade das von Dir angesprochene Copy & Paste zwar auch in jedem einzelnen Fall schneller, aber: Der Kunde ruft an und sagt dass an der Ausgabe von Stelle X ein Bug ist. Wahrscheinlich ein Umrechnungsproblem oder falsche verwendete Einheiten. Es fällt auf, dass eine bestimmte Funktion einen Bug hat, der zu einem falschen Ergebnis führt. Mitarbeiter A fixt den Bug und deployed die Applikation neu.

Zeitsprung, Irgendwann ein paar Wochen vorher: Mitarbeiter B hat die Aufgabe, eine Exportfunktion zu schreiben, die die Ausgabe, die an Stelle X gemacht wird, enthält. Das Sind Daten, die ein zulieferer zu Produktion von Teilen benötigt. Er kopiert genau den fehlerhaften Teil, anstelle ihn wiederverwendbar zu machen und zu benutzen (würde länger dauern, ist 'nicht pragmatisch', der Code ist mit der Kopie besser lesbar, und sowieso ist das ja eher RAD und das andere OOP Overkill).

Was genau das Problem ist? Der Fehler ist jetzt immer noch am Programm, denn Mitarbeiter A hat den Fehler an Stelle X und gefixt und, weitsichtig wie er war, sogar noch geschaut von welchen Stellen der Code noch benutzt wird. An einer weiteren Stelle musste die Ausgabe noch um die, jetzt korrekte, Einheit angepasst werden, aber mehr war nicht zu machen. Das der Code von einem anderen Kollegen an Stelle Y kopiert wurde, davon weiss er nichts. Selbst wenn er mit so etwas rechnen müsste und er bei seinen Kollegen fragt, kann sich B nicht mehr daran erinnern, genau den Code verwendet zu haben. Ist ja schon ein paar Wochen her, und die Exportfunktion schon lange vergessen.

Ohne zu wissen, dass der Fehler jetzt an stelle B immer noch im Programm (und damit im Export für den Zulieferer) ist - er sieht das korrekte Ergebnis ja an Stelle A - bestellt der Kunde anhand der Daten einen Großauftrag beim Zulieferer. Die gelieferten Kabelbäume für den A380 sind zu kurz - es gibt einen Millionenschaden. Weil irgendjemand Copy & Paste benutzt hat.

Zitat von bernerbaer:

Nein, ich gehöre nicht zu den Programmierern die einfach Buttons und Edits auf die Form klatschen! Ich bin ein Programmierer der sich überlegt was er macht und den Aufwand und Ertrag abschätzt. Wo Trennung von GUI und Anwendungslogik sinn macht, setze ich es auch ein. Aber ich bin nicht ein Gläubiger der macht, was die Mehrheit sagt.

Eigentlich sagt es nur eine Minderheit, das die Trennung von Logik und UI Sinnvoll ist. Das Problem ist, dass es leider keine Wirtschaftlichen Auswertungen darüber gibt, wieviel Geld und Zeit es kostet, es vorher ein einziges mal ein wenig aufwendiger zu implementieren und wieviel Geld un Zeit es kostet, hinterher in kopiertem Code, der zudem durch fehlende Trennung / zu starke Bindung schlecht bis gar nicht automatisiert Testbar ist, Bugs überhaupt an allen Stellen zu lokalisieren und zu fixen, ggf. mehrfach, und das alles hinterher wieder manuell durchzutesten.

Ich würde jede Wette eingehen, die Sicherheit und die Zuverlässigkeit, die eine sauber aufgesetzte Applikation bietet (im Sinne von: Fehler fallen durch automatisierte Tests sofort auf, durch saubere Trennung ist alles Testbar, durch saubere Trennung lassen sich neue Features leichter und schneller einbauen, weil sie schon funktionierenden Code absolut nicht beeinflussen können), wiegen den scheinbaren Vorteil den RAD bietet (ein wenig schneller bis zum ersten sichtbaren Ergebnis) um längen auf. Und zwar in nahezu jedem einzelnen Fall.

[bernerbaer]

Zitat von Phoenix:

Zitat von bernerbaer:

sorry, wenn ich am Thread vorbei rede. Aber zurück zum Beispiel der Addition. [...] Wiederverwendbarkeit des Codes? Kann ich mit Copy und Paste schneller, bessere Lesbarkeit des Codes?)

Du arbeitest wahrscheinlich nicht an größeren Projekten. Bei einem kleinen Projekt, an dem man alleine arbeitet, mag das pragmatisch und effizient sein. In einem größeren Projekt, wo Teams >= 10 Personen arbeiten ist z.B. gerade das von Dir angesprochene Copy & Paste zwar auch in jedem einzelnen Fall schneller, aber: Der Kunde ruft an und sagt dass an der Ausgabe von Stelle X ein Bug ist. Wahrscheinlich ein Umrechnungsproblem oder falsche verwendete Einheiten. Es fällt auf, dass eine bestimmte Funktion einen Bug hat, der zu einem falschen Ergebnis führt. Mitarbeiter A fixt den Bug und deployed die Applikation neu.

Sorry, da habe ich mich missverständlich ausgedrückt, selbstverständlich mache ich nicht copy und paste innerhalb (m)eines Projektes. Ich habe es folgendermassen gemeint: Ich habe eine Funktionssammlung und kopiere genau einmal die benötigte Funktion in eine Unit (m)eines Projektes.
In meiner über 30 jährigen Laufbahn als Softwareentwickler konnte ich noch _nie_ eine komplette Klasse eines Projektes in einem anderen Projekt wiederverwenden, aber hunderte von Funktionen die ich einfach aus meiner Sammlung kopiere und eine Funktionsunit einfügen kann (oder aber in dll's die von mehreren Programmen wiederverwendet werden können).

Nun jedermann soll vorgehen wie es die Firmenpolitik vorgibt oder der jeweilige Einzelprogrammierer es mag. Solange ich keine masochistischen Gelüste in mir spüre, verwende _ich_ für Projekte mit einer GUI ein RAD-Tool.

Manchmal kommt es mir vor, gewisse Programmierer arbeiten nach Zeilenentschädigung (das habe ich vor über 30 Jahren auch gemacht als freischaffender Journalist für Computerzeitschriften, da habe ich auch des öftern meinen Code aufgeblasen um mehr Geld für die Finanzierung des Studiums zu erhalten - und hunderte haben dann diesen Code mühsam abgetippt .

[Luckie]

Und wenn du feststellst, dass die Funktion in der Sammlung einen Fehler enthält, dann durch suchst du alle deine Projekte um dann in jedem einzelnen den Fehler zu beheben? Wenn du nicht zentral auf diese eine Unit zugreifen willst (Ist immer etwas mühsam, wenn man es OpenSource verteilt, alle benötigten Units für das Archiv zusammenzusuchen.), dann ändere den Fehler in der Unit und kopiere sie in den Projektordner der betroffenen Projekte. Wenn du dann noch Buildscripte verwendest, brauchst du noch nicht mal die IDE zu öffnen. So mache ich das immer.