Trennung von GUI und Logik, wie geht ihr vor?

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

[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 von stahli:

... 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 von Mavarik:

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.

[Mavarik]

Zitat von freimatz:

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.

Also: Ich habe nie statische Datenbankverbindungen, nie ein Datenmodul, nie eine Datenbankkomponente irgendwo hin geklickt. Kein DataSource kein NIX.

Ich erzeuge alles dynamisch und behandle alles als währe es ein REST Request zu einem Server. Mein Model hat jeweils eine Memory Repräsentation eines Datensatzes oder einer Liste von Datensätzen. i.d.R. nicht mehr als doppelte der StringGridInViewRowCount.

Für die Bindung von View->ViewModel habe ich eine eigene Verbindungsklasse geschrieben für die andere Richtung erzeuge ich einen PropertyChange Multicast-Event.

Mein Model kann i.d.R. auch immer ein Autosync (für Apps) lokale SQLite <-> REST Server. Beim schreiben, wird immer erst in die lokale SQLite geschrieben und dann im Thread per REST zum Server beim Lesen wird - falls eine Internetverbindung besteht erst ein TimeStamp-Vergleich ausgeführt und falls der Server nicht neuere Daten hat aus der lokalen SQLite gelesen...

Da ich immer - bei jeder Software - diesen Ansatz verfolge, brauche ich bei einer Software mit einem ständigen Datenbankzugang, nur das localSync Interface weglassen und alles läuft ohne den Zwischenschritt...

Ich hoffe das beantwortet Deine Frage und war nicht zu offtopic...

Mavarik

[freimatz]

Es geht doch immer noch um "Trennung von GUI und Logik"

DAs was MVVM betrifft sehe ich in deinem Satz: "Für die Bindung von View->ViewModel habe ich eine eigene Verbindungsklasse geschrieben für die andere Richtung erzeuge ich einen PropertyChange Multicast-Event."
Der Rest ist doch alles ViewModel<->Model - oder?
Und das tritt doch auch unr zu wenn man eine DB hat. Bei uns hat das UI, das Viewmodel und das Model erst mal nichts mit DB zu tun.

Die oben geschriebene Verbindungsklasse - gibts die dann für jede View seperat implementiert?