Trennung von GUI und Logik, wie geht ihr vor?

[divBy0]

Ob die Klasse jetzt trivial ist oder nicht sollte egal sein. Mir geht es einfach um die perfekte Trennung zwischen GUI und Logik und dafür sollte eine solche einfache Klasse doch ausreichen, oder brauchen wir ein "größeres" Beispiel.

Die Antworten zu dem Thema zeigen mir aber auch, dass es anscheinend nicht so einfach zu sein scheint bzw. die Herangehensweisen stark auseinander gehen.

[Stevie]

Zitat von divBy0:

Die Antworten zu dem Thema zeigen mir aber auch, dass es anscheinend nicht so einfach zu sein scheint bzw. die Herangehensweisen stark auseinander gehen.

Mein Vorgehen lehnt sich halt an MVVM an, wie es WPF vormacht. Zwischen dem View und dem ViewModel gibt es keine Abhängigkeit, die View wird quasi einfach nur oben drauf gesteckt und mit den Bindings festgetackert. Ich will nicht sagen, dass das revolutionär in Delphi ist, aber ich hab es in der Form noch nicht gesehen, die meisten Ansätze laufen auf MVC/MVP hinaus. Und das ist mir nicht entkoppelt genug und produziert zu viel Code.

[divBy0]

@Stevie: In deinem Beispiel fehlt DSharp... Ist das deine Binding-Lösung? Wo kann ich mir die Unit runterladen?

[Stevie]

Zitat von divBy0:

@Stevie: In deinem Beispiel fehlt DSharp... Ist das deine Binding-Lösung? Wo kann ich mir die Unit runterladen?

Hab mal meine Sig angepasst

[SebE]

Zitat:

Mein Vorgehen lehnt sich halt an MVVM an, wie es WPF vormacht. Zwischen dem View und dem ViewModel gibt es keine Abhängigkeit, die View wird quasi einfach nur oben drauf gesteckt und mit den Bindings festgetackert. Ich will nicht sagen, dass das revolutionär in Delphi ist, aber ich hab es in der Form noch nicht gesehen, die meisten Ansätze laufen auf MVC/MVP hinaus. Und das ist mir nicht entkoppelt genug und produziert zu viel Code.

Dass ich auch der Meinung bin, dass MVC nicht genug entkoppelt, habe ich bereits geschrieben - man muss eben seine eigenen Architekturen (-Muster) erstellen.

In C# würde man die Bindings mit XAML herstellen.
Mir persönlich geht das aber zu weit - ich möchte im Code nachvollziehen können, was wann wo verbunden wird.
Das "schlimmste" ist in meinen Augen, dass man Methoden, Objekte (analog Properties) mit Zeichenketten ausweist.
TBinding.Create(add, 'Zahl1', MainForm.edNumber1, 'Text'); DoPropertyChanged('Ergebnis'); Es werden die Elemente der Programmiersprache nicht mehr als Symbole vestanden bzw. angesprochen.
Kann ich mich nicht mit anfreunden.
Aber die Idee dahinter finde ich super.

[Stevie]

Zitat von SebE:

Das "schlimmste" ist in meinen Augen, dass man Methoden, Objekte (analog Properties) mit Zeichenketten ausweist.
Es werden die Elemente der Programmiersprache nicht mehr als Symbole vestanden bzw. angesprochen. Kann ich mich nicht mit anfreunden.

Absolut korrekt. Das ist auch mein persönlich größter Kritikpunkt - daher ja auch mein sehnlicher Wunsch nach property references.

Übrigens auch in .Net wird mit strings gearbeitet. Der Pluspunkt gegenüber der Delphi Lösung ist halt, dass das XAML auch geprüft wird. Aber wenn du beim NotifyPropertyChanged deine Property falsch schreibst, biste genauso gekniffen (außer du nutzt Prism, wo das durch das keyword notify geregelt wird )

[Phoenix]

Zitat von SebE:

Mir persönlich geht das aber zu weit - ich möchte im Code nachvollziehen können, was wann wo verbunden wird.

Aber genau darum geht das doch das entkoppeln. Das es eben genau nicht mehr im Code steht sondern lediglich noch Deklarativ geschieht.

Wenn Du das im Code machst, produzierst Du zum einen wieder viel mehr Code (der neue Fehler enthalten kann), zum anderen verlierst Du genau die Flexibilität, die solche Binding-Mechanismen gerade erlauben sollen.

Der Trick ist doch genau der, Elemente austauschen zu können, die nichts voneinander wissen. Code muss zwangsläufig auf beiden Seiten die Details kennen, um sie aneinander zu koppeln. Deklaratives binding hingegen erlaubt es Dir, sowohl die View als auch das Model auszutauschen, ohne dass es hier zu einer Code-Änderung an irgend einer anderen Stelle kommen muss.

Das ist ja auch genau das Problem an MVC: Der Controller muss View und Model kennen, um sie aneinander zu docken.
MVVM-Patterns hingegen abstrahieren selbst das Model (reine Business-Logik) noch einmal mit UI-Logik (Erlaubte Aktionen, Dargestellte Werte etc.), und nur die View bindet sich deklarativ ans ViewModel.

Deswegen funktioniert auch sowas wie das hier: http://jsfiddle.net/rniemeyer/aDahT/ mit so ungeheuer wenig Code.

[SebE]

Zitat von Phoenix:

Aber genau darum geht das doch das entkoppeln. Das es eben genau nicht mehr im Code steht sondern lediglich noch Deklarativ geschieht.

Wenn Du das im Code machst, produzierst Du zum einen wieder viel mehr Code (der neue Fehler enthalten kann), zum anderen verlierst Du genau die Flexibilität, die solche Binding-Mechanismen gerade erlauben sollen.

(fett durch mich)
Punkt 1: stimmt absolut.
Punkt 2: Ich weiß gerade nicht, was ich von Hand nicht machen könnte, was mir Bindings erlauben.

Zitat von Phoenix:

Der Trick ist doch genau der, Elemente austauschen zu können, die nichts voneinander wissen. Code muss zwangsläufig auf beiden Seiten die Details kennen, um sie aneinander zu koppeln. Deklaratives binding hingegen erlaubt es Dir, sowohl die View als auch das Model auszutauschen, ohne dass es hier zu einer Code-Änderung an irgend einer anderen Stelle kommen muss.

Beim Verbinden muss immer Information offen gelegt werden.
Beim Binding muss man angeben, welche Property verwendet werden soll.
Ich mache das mit Abstraktionen, die das - und nur das - enthalten, was der Benutzer der konkreten Implementierung wissen darf.
Schnittstellen muss man immer angeben.

Klar ist es mehr Aufwand, aber so viel auch wieder nicht: nach dem Anpassen der Schnittstelle, die richtigen Objekte erzeugen.
Vorteil: der Compiler sagt mir, wenn ich falsche Informationen beziehen möchte.

Zitat von Phoenix:

Das ist ja auch genau das Problem an MVC: Der Controller muss View und Model kennen, um sie aneinander zu docken.

(fett durch mich)

Dass der Controller das Model kennen muss, ist eigentlich kein Problem (meine Controller rufen nur Model-Methoden auf).
Für den markierten Teil wird ein Presenter eingefügt, von dem der Controller auch nur die Abstraktion kennt.

Meine Architektur:
Model: klar!
Controller: wählt zu Beginn den Presenter/die View aus; bestimmt, was die Anwendung kann; leitet Anweisungen an Model
Presenter: UI-Logik (Weiterleiten von Eingaben); Formatierung der Ausgabe ;Erzeugen von UI-Objekten auf Anfrage des Controllers (auf Anfrage des Models)
View: Leitet Eingabe-Events an den Presenter weiter; sieht trollig aus

[bernerbaer]

OOP bis zum "Gehtnichtmehr"! Delphi ist für mich ein RAD-Tool und OOP ist kein Dogma. Es gibt nun einfach Dinge, die im praktischen Entwickleralltag sinnlos sind. Eine strikte Trennung von GUI und Anwendungslogik ist in Delphi nicht immer zwingend und verhindert manchmal sogar die Übersichtlichkeit und Lesbarkeit des Codes bei kleinen Projekten. Leider habe ich den Link nicht mehr gefunden, aber irgendwer hat mal ein Horrorbeispiel in OOP für ein Hello-Word Programm geschrieben (vielleicht kennt ja hier jemand das Beispiel). Also meine Ansatz: Auslagerung in externe Klassen nur dann wenn es Sinn macht und/oder die Lesbarkeit des Codes verbessert.

[stahli]

Das stimmt, aber um so größer und komplexer ein Projekt werden wird, um so wichtiger wird eine Trennung.
Es ist eine Frage des Frameworks, wie komfortabel die Bindung der beiden Ebenen realisiert werden kann.
Die Erstellung der Datenebene und der GUI-Ebene für sich sollte jeweils einfacher und übersichtlicher werden.