Trennung von GUI und Logik, wie geht ihr vor?

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

[mkinzler]

Zitat:

Und das tritt doch auch unr zu wenn man eine DB hat.

Ein Model hat man auch ohne Datenbank.

[freimatz]

Ja eben. Mich irriitert dass er so viel schreibt, was ich eher in Richtung DB sehe wie REST, Server, Datensatz, Datensätze, Grid, SQLite und Datenbankzugang.
Aber egal, mir gings um MVVM und da eher um UI<->Viewmodel

[Mavarik]

Zitat von freimatz:

Ja eben. Mich irriitert dass er so viel schreibt, was ich eher in Richtung DB sehe wie REST, Server, Datensatz, Datensätze, Grid, SQLite und Datenbankzugang.
Aber egal, mir gings um MVVM und da eher um UI<->Viewmodel

Es kommt ein bisschen darauf an, ob die Datenhaltung im ViewModel oder im Model ist.

Hier findet man oft sehr unterschiedliche Ansätze..

Nach dem Motto : Das ViewModel hat nur die Status- und Steuerungslogik die Daten liegen immer im Model...

oder

Das Viewmodel hält zusätzlich die Daten der View und das Model ist nur für eine Datenbank-Schicht da.

Ich habe bereits beide Ansätze versucht und verwende es so wie es optimal für die Aufgabe ist.

Ob man den "Aufwand" triebt für ein Fenster, dass keine "Daten" benötigt ist die andere Frage...

[Stevie]

Zitat von stahli:

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.

Und wo implementierst du, dass man einen Fahrer mit nur Führerschein Klasse B nicht in den 12-Tonner setzen kann?

Zitat von Mavarik:

Es kommt ein bisschen darauf an, ob die Datenhaltung im ViewModel oder im Model ist.

Hier findet man oft sehr unterschiedliche Ansätze..

Nach dem Motto : Das ViewModel hat nur die Status- und Steuerungslogik die Daten liegen immer im Model...

oder

Das Viewmodel hält zusätzlich die Daten der View und das Model ist nur für eine Datenbank-Schicht da.

Ich habe bereits beide Ansätze versucht und verwende es so wie es optimal für die Aufgabe ist.

Ob man den "Aufwand" triebt für ein Fenster, dass keine "Daten" benötigt ist die andere Frage...

Eigentlich ist es recht unmissverständlich definiert - siehe https://msdn.microsoft.com/en-us/lib...8246.aspx#sec7

Die Frage ist eher, wie sehr man die Daten kapselt. Wenn jemand sagt, meine Daten sind in Form eines Datasets, dann kann man das natürlich argumentieren, dass das VM die einfach durchreicht.
Ob man damit allerdings eine gute Testbarkeit und Kapselung erreicht, stell ich mal in Frage.

Auch bestimmte Anforderungen beeinflussen, wie sehr das VM das M duplizieren muss. Es gibt zum Beispiel VM Basisimplementierungen, die das Edit/Save/Cancel implementieren und dann an das View bloß eine Kopie der Modelldaten binden und beim Save bzw Cancel die Änderungen zurück kopieren oder verwerfen.