Trennung von GUI und Logik, wie geht ihr vor?

[Mavarik]

Zitat:

Zitat von freimatz (Beitrag 1387583)

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... :stupid:

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:

Zitat von freimatz (Beitrag 1387622)

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:

Zitat von stahli (Beitrag 1387569)

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:

Zitat von Mavarik (Beitrag 1387624)

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.

[Fritzew]

Zitat:

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

Wir benutzen diesen Ansatz eigentlich immer. CAD Bereich. Der Anwender ändert etwas in einem Fenster und bekommt das direkt visualisiert. Da kann er dann "rumspielen" und bei Ok bleibt die letzte Änderung erhalten und wird committed. Ansonsten geht es zurück auf den Original Stand. Hat den Vorteil dass der Undo Buffer erst bei OK belegt wird.

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1387626)

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.

Ja "unmissverständlich" wird gesagt, dass das VM die Daten aus dem Model auch ggf. Interpretiert und ggf. anders an die View weiter gibt.

Also hat das VM ggf. auch intern eine eigenen Datenbestand für die View...

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1387635)

Zitat:

Zitat von Stevie (Beitrag 1387626)

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.

Ja "unmissverständlich" wird gesagt, dass das VM die Daten aus dem Model auch ggf. Interpretiert und ggf. anders an die View weiter gibt.

Also hat das VM ggf. auch intern eine eigenen Datenbestand für die View...

Der Kernpunkt ist, dass das VM die Kontrolle darüber hat, was in beide Richtungen fließt.

Lass uns nochmal kurz definieren, was bei MVVM Model und ViewModel sind.

Bei dem Model kann es sich um eine simple TCustomer Klasse mit 5 string Eigenschaften und sonst nix handeln oder um eine TSpeicherDruckUndSchickEmailsKlump Klasse mit siebenundöffzig Methoden.

Das ViewModel abstrahiert die Funktionialität des Models, die in der View benutzt wird und bereitet sie entsprechend auf. Wenn ich von den 5 Eigenschaften nur 3 Anzeige, dann gibt es möglicherweise nur genau diese 3 Eigenschaften im ViewModel (caching, edit, save, cancel etc mal außen vor gelassen). Wenn es nun so sein soll, dass ich die 3. Eigenschaft nur befüllen kann, wenn die 2 anderen Eigenschaften bestimmte Werte haben, dann gibt es eine "Eigenschaft3Enabled" Eigenschaft im ViewModel, welche an das entsprechende UI Control für diese Eigenschaft gebunden wird und durch Änderungen der anderen beiden Eigenschaften im ViewModel beeinflusst wird. Hierbei sorgen die Bindings und ein entsprechende Benachrichtigungssystem für das Updaten in beide Richtungen:

In der UI in den Controls für Eigenschaft 1 oder 2 was geändert -> binding aktualisiert das VM -> "Eigenschaft3Enabled" wird ggf verändert -> "Eigenschaft3Enabled hat sich geändert" Notification triggert -> binding bekommt das mit -> UI Control für Eigenschaft 3 wird entsprechend an oder ausgeschaltet

D.h. irgendwelche Businesslogik wird in den meisten Fällen nichtmal im ViewModel gehandhabt sondern im Model. Das ViewModel ist quasi nur die Abstraktion der UI. Dort steht drin, dass bei der Konstellation XY die CheckBox Z angezeigt wird oder nicht.

Und genau jetzt ergibt sich oft die Tücke, dass gewisse Dinge dann doch irgendwie Businesslogik sind und Teil des Models sind (komplexe Regel validierung, etc), aber doch bitte in der UI reflektiert werden soll. Das muss dann immer komplett durch das ViewModel hin und zurück fließen - guckstu https://stackoverflow.com/questions/...or-a-viewmodel

Das heißt also, dass hier das VM schon mehr Teil der UI als der Businesslogik ist - schaust du hier: https://stackoverflow.com/questions/...ttern-and-mvvm
Wenn du dir den 2. Grund anschaust, warum MVVM so toll ist/sein soll, dann wird klar, warum das in Delphi in dieser Form so schnell zusammen fällt, da gibs kein Blend. Rapid Prototyping funktioniert bei uns ein bisschen anders (TPrototypeBindSource, TClientDataSet etc).

[stahli]

Zitat:

Zitat von Stevie (Beitrag 1387626)

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

Mit Validierungsregeln an Klassen und an Properties.
Die GUI weiß, dass es Validierungsregeln geben kann und wird diese Informationen entsprechend automatisch benutzen.
Im Bild (Machbarkeitstest) ist schon mal eine Regel hinterlegt (das können Attribute wie NotEmpty oder ganze Funktionen sein) und die GUI zeigt den Regelverstoß an.
Außerdem zeigt sie gleich noch automatisch an, wenn in einem anderen Client gerade die selbe Eigenschaft geändert wird.
Man braucht also nur die Regeln definieren und das Framework macht den Rest.

Übrigens kann man dann auch einfach z.B. einen OkButton.Valid an MyPerson.Valid binden. Der wird dann Enabled, wenn das Objekt valide ist und sonst listet er die Probleme auf.
Oder man bindet OkButton.Enabled an MyPerson.IsValid, so dass er nur enabled/disabled wird und zeigt die Validierungsprobleme an den anderen Controls an.

Das Projekt ist allerdings noch in Arbeit aber dort will ich hin und teilweise funktioniert das auch schon super.


Bezüglich Deines Beispiels "nicht in den 12-Tonner setzen kann" müsste man klären, was das genau heißt und wo das Problem auftreten kann.
Auf jeden Fall müsste eine Eigenschaft oder eine Klasse die Validität/Akzeptanz prüfen.
Wenn das hinein setzen z.B. über Drag&Drop erfolgt, müsste der LKW prüfen, ob der Fahrer den LKW fahren darf und ggf. DropAccept verweigern.
Der Fahrer selbst ist ja nicht invalide, aber beim Starten des LKW müsste ggf. ein Fehler ausgegeben werden.
Genau kann ich das jetzt so auch nicht sagen. Jedenfalls müssen die Klassen und Properties Validierungen oder einfache Checks/Funktionen ausführen, die die GUI abfragen kann.
An der Stelle, wo ich jetzt etwas schwimme, müsste man bei Einsatz eines Controllers sicher auch gut überlegen, wie man das 12-Tonner-Problem genau umsetzt und in der GUI darstellt.

Zitat:

Zitat von Stevie (Beitrag 1387642)

Das ViewModel abstrahiert die Funktionialität des Models, die in der View benutzt wird und bereitet sie entsprechend auf. Wenn ich von den 5 Eigenschaften nur 3 Anzeige, dann gibt es möglicherweise nur genau diese 3 Eigenschaften im ViewModel (caching, edit, save, cancel etc mal außen vor gelassen).

Eben diese Doppelung will ich mir ersparen und binde einfach nur drei Controls an 3 von 5 Eigenschaften.