Trennung von GUI und Logik, wie geht ihr vor?

[p80286]

Wenn ich die letzten Beiträge richtig verstanden habe, brauche ich ein Framework um Oberfläche und (Geschäfts-)Logik von einander zu trennen?

Gruß
k-H

[mkinzler]

Ein solches könnte dies erleichtern. Ohne muss man händisch viel glue code, welcher sehr ähnlich ist, immer wieder schreiben.

[p80286]

Zitat:

Zitat von mkinzler (Beitrag 1387562)

Ein solches könnte dies erleichtern. Ohne muss man händisch viel glue code, welcher sehr ähnlich ist, immer wieder schreiben.

danke für die prägnante Ausführung!

gruß
K-H

[stahli]

@p80286

Kannst Du Deine Haltung mal etwas präzisieren?
So richtig ist mir nicht klar, worauf Du raus willst...


@all

Ich bevorzuge grundsätzlich Lösungen mit Databinding, die ohne Controller oder Presenter auskommen.
Dazu müssen Controls halt in der Lage sein, vorhandene Datenstrukturen zu erkennen und die GUI daraufhin anzupassen.
Eine ListBox wird also an die Autoliste des Fuhrparks gebunden und ein Edit an die Eigenschaft Lastname des Fahrer(objekt)s.
Ich möchte für die Verbindungen einfach keinen Code schreiben müssen.
Natürlich müssen dafür die Controls selbst wissen, wie sie mit der Datenschicht kommunizieren können.

[p80286]

@Stahli
Ich hatte bisher den Eindruck, daß unbedingte Voraussetzung für die Trennung von Oberfläche und Logik ein Framework und die intime Kenntnis von MVC bzw. MVVM o. ä. ist. Wenn die "Denke" nicht vorhanden ist, helfen alle Hilfsmittel nicht weiter. Man muß also zuerst die Notwendigkeit einsehen und Verstehen, und dann kann man sich an irgendwelchen Thesen orientieren.

Und Markus kann nun mal unerreicht prägnant formulieren.

Gruß
K-H

[stahli]

Ah, ok, ich hatte da etwas Sarkasmus aus Deinen Beiträgen heraus gelesen.
Aber ich nehme gleich meine Tropfen ein, dann wird das schon wieder! :stupid:

[Mavarik]

Hallo Zusammen...

Schade das es von den Forentage keine Videos gibt...

In mein MVVM-Lite Vortrag habe ich genau gezeigt, wie einfach man MVVM (oder was ich dafür halte) ohne Framework mit wenigen Handgriffen machen kann.

Abgesehen davon : je weniger ich im OI klicken muss, umso schneller bin ich...
Wenn man dann noch die ein oder andere Factory hat geht MVVM kaum langsamer zu programmieren als IDE Klick on Button and go...
Ein bisschen mehr aufwand um zwischen den einzelnen Schichten hin und her zu wechseln...

Nix gegen Olaf's Video, Theorie ok, aber die Umsetzung würde ich so Hardcoded NIE machen. Lieber ein Interface erzeugen, dass Übergeben, am besten aus einer Factory. Außerdem verfolge ich gerne den CRUD Ansatz als Basis zu nehmen, dass erleichtert immer eine Umsetzung für eine App wo die Daten auf einem REST-Server liegen usw.

Mavarik

[stahli]

... wolltest Du dazu nicht mal ein kleines Video machen?

[Mavarik]

Zitat:

Zitat von stahli (Beitrag 1387579)

... wolltest Du dazu nicht mal ein kleines Video machen?

ja, will ich immer noch.
[OT]
Ich schiebe leider noch einen Berg von Aufgaben vor mehr her, bis dafür Zeit ist...
[/OT]

[freimatz]

Zitat:

Zitat von Mavarik (Beitrag 1387578)

Nix gegen Olaf's Video, Theorie ok, aber die Umsetzung würde ich so Hardcoded NIE machen. Lieber ein Interface erzeugen, dass Übergeben, am besten aus einer Factory. Außerdem verfolge ich gerne den CRUD Ansatz als Basis zu nehmen, dass erleichtert immer eine Umsetzung für eine App wo die Daten auf einem REST-Server liegen usw.

Du redest schon von MVVM? Wir machen seit vielen Jahren MVVM (nennen es zumindest so). Interfaces sind da auch dabei. Aber ich habe keinen Schimmer was das mit CRUD zu tun hat. Wie geht das Binding bei dir? Also wie kommen z.B. Double Werte vom viewmodel an eine TEdit-Control? Und wie bekommt das viewmodel Bescheid wann sich was geändert hat?
Bei uns macht man in der UI z.B.:
BindingManager.NewBinding(viewmodel.TED1, edTED1, BindingModeET.Bidirectional);
Da ist TED1 ein view item im viewmodel und edTED1 ein Edit-Control.