Trennung von GUI und Logik, wie geht ihr vor?

[Stevie]

Nativ wie gesagt mit meiner Library ab Delphi 2010. Das Prinzip dahinter ist aber genauso mit Delphi 7 realisierbar (halt mit einigen Abstrichen bzgl der RTTI und Generics z.B.)

Eingangsbeispiel mal mit meinen DataBindings realisiert im Anhang

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

[SebE]

@Stevie:
Die Trennung ist wirklich stark, da diese komplett von der "Framework-Magic" übernommen wird.

Meine Lösung entspricht weitgehend meiner Lösung auf Seite 1 mit dem Zusatz:

Delphi-Quellcode:

procedure List.SelectIndexChange(...);
begin
  TOperation(Form1.List1.SelectedItem).SetVisualComponent(MyVisualAttributes);
end;

// ---

type
  TVisualAttributes = class
    op1, op2: TEdit;
    result: TEdit;
    [...]
  end;

TAddition, TSubtraction, ... sind von TOperation abgeleitet.
In TOperation.SetVisualComponent(vc) wird die visuelle Komponente im Business-Objekt ersetzt und es werden alle ChangeEvents aufgerufen:

Delphi-Quellcode:

procedure TOperation.SetVisualComponent(vc: TVC);
begin
self.visualComponent := vc;

if vc <> nil then begin
  resultChangeEvent(...); // hier muss man sich überlegen,
                          // ob die Werte (Zahl1, Zahl2) vorhanden sind bzw. sein sollen.
                          // Sonst: nach SetVisualComponent
                          // TOperation(Form1.List1.SelectedItem).Execute aufrufen
  end;
end;

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

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