Trennung von GUI und Logik, wie geht ihr vor?

[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