MVC -- Daten-Validierung, komplexe Models und deren Darstellung

[s.h.a.r.k]

So, habe nun doch noch ein paar Fragen zum MVC-Pattern Im Allgemeinen habe ich das ganze eigentlich durchdrungen, nur habe ich da hin und wieder doch Probleme. Zum einen mit der Validierung der eingegebenen Daten. An der Stelle finde ich es immer ganz schick, wenn die eingegebenen Daten live validiert und entsprechende Fehler in einer Liste ausgegeben werden, evtl. direkt nebem dem Control, in dem falsche Daten stehen. Gut, dieser Gedanke impliziert, dass bei jeder Änderung an der Eingabe dem Controller mitgeteilt wird, dass Daten auf der View aktualisiert werden und dieser die Daten zu validieren hat. Passt alles, so können diese ins Model übernommen werden. Oder sollte die Validierung vielleicht ins Model? Aber wie sollte die Validierung ablaufen? Im Setter? Die nächste Frage wäre dann, wo werden die Fehlermeldungen gespeichert? In einer Liste? Oder werden beim Setzen der Werte Exception geworfen? An der Stelle wäre es eben interessant, was State of the Art ist bzw. wie ihr das handhabt.

Gut, nun zu den komplexeren Models: es gibt ja beliebige Abhängigkeiten von Models untereinander -- nur um ein kleines Beispiel zu nennen: ein Schüler ist in einer Klasse, die einen Lehrer hat. So... Nun besteht doch das Problem, dass eine View von zwei Models abhängt, zumal eine View für beliebig viele Models da sein kann -- sowas hängt ja auch ungemein von der erwünschten Usability ab. Wenn ich hier von einer View rede meine ich explizit ein Control und nicht gleich eine ganze Form! Daher sehe ich das MVC-Pattern eher als MVsC -> Model, Views, Control, d.h. dass ich für ein Model mehrere Views bzw. Model-übergreifende Views haben kann -- aber wie handle ich sowas dann?

Also, auf gehts

[webcss]

Zitat von s.h.a.r.k:

..., wenn die eingegebenen Daten live validiert und entsprechende Fehler in einer Liste ausgegeben werden, evtl. direkt nebem dem Control, in dem falsche Daten stehen. Gut, dieser Gedanke impliziert, dass bei jeder Änderung an der Eingabe dem Controller mitgeteilt wird, dass Daten auf der View aktualisiert werden und dieser die Daten zu validieren hat.... Oder sollte die Validierung vielleicht ins Model? Aber wie sollte die Validierung ablaufen? Im Setter?

Die Validierung sollte immer "so nah" wie möglich an den Daten passieren, also im Setter des Models. Via Observer Pattern hast Du die Möglichkeit, Fehler "soft" via Statusmeldung oder bubble hint oder Farbänderung des Controls etc. zu signalisieren. Spätestens sollte eine Validierung vor dem speichern durchgeführt werden.
Noch mehr "live" ist die Validierung bzw. Filterung der Eingabe, z.B. keine Buchstaben, wo nur Zahlen gewünscht sind (MaskedEdit oder Key Preview).

Zitat von s.h.a.r.k:

Gut, nun zu den komplexeren Models: es gibt ja beliebige Abhängigkeiten von Models untereinander ... d.h. dass ich für ein Model mehrere Views bzw. Model-übergreifende Views haben kann -- aber wie handle ich sowas dann?

Auch hier ist das Observer Pattern Dein Freund, Änderungen am Model werden direkt durch alle observierenden Controls reflektiert.

[Sir Rufo]

Mir gefällt da die Methode von DSharp wesentlich besser und die Verbindung zwischen dem Model und der View via Binding zu realisieren.
Der Validator sitzt dabei im Binding.

[stahli]

Ok, das Thema interessiert mich ja auch schon länger. Das Resultat meiner Versuche sind die odControls.

Über die ganzen Patterns habe ich auch einiges gelesen, aber das ist insgesamt doch recht schwammig (liegt ja in der Natur der Sache).
Ich gehe davon aus, dass häufig nicht mal jeder das gleiche meint, selbst wenn gemeinsam diskutiert wird.

Daher habe ich mich selbst herangetastet und folgende Lösung:

Die Daten + Geschäftslogik liegen in Objekten, die wieder andere Objekte enthalten können. Das oberste Objekt beeinhaltet also letztlich alle Daten (kennt aber nur seine direkten SubObjekte) und sämtliche Geschäftslogik.

Meine Controls sind von Standardcontrols abgeleitet, dem ein "Controler" hinzugefügt ist. Dem Objekt kann ein Datenobjekt und ein PropertyName zugewiesen werden.

Alle Controler werden beim Erzeugen in einer Liste eingetragen und beim Zerstören wieder daraus gelöscht.

Erfolgt in einem Datenobjekt eine Änderung, wird ein Timer mit einer kleinen Verzögerung gestartet. Erfolgt eine weitere Änderung wird der Timer neu gestartet. Erfolgte einige Zeit keine weitere Änderung, feuert der Timer und informiert alle registrierten Controler über eine Änderung. Diese rufen für ihr Owner-Control Invalidate auf.

Wenn das Control sichtbar ist bzw. das nächste mal angezeigt wird, holt es sich den aktuellen Wert von seinem Controler ab (dem Control ist es dabei egal, was das für ein Objekt ist).
Wird der Wert in dem Control geändert (z.B. in TodEdit) übergibt dieses den neuen Wert an sein Control, das den Wert "in das Objekt schreibt".

Eine Validierung führe ich i.d.R. erst im Setter bzw. der Geschäftslogik durch.

Formulare erhalten auch einen Controler, so dass ein Formular für ein Objekt und seine Unterobjekte "personalisiert" wird.

Ein Datenobjekt kann seine Daten speichern und seine Unterobjekte veranlassen, das ebenfalls zu tun.
Beim Laden von Daten werden Objekte (z.B. in Listen) vorher automatisch erzeugt.
Darum muss man sich also nicht mehr kümmern.

In welches Pattern das Ganze nun passt (und ob überhaupt) ist mir noch nicht ganz klar geworden.

Wichtig ist mir, dass ich komplexe Projekte mit möglichst wenig Aufwand und möglichst flexibel erstellen kann. Die Trennung von Daten+Geschäftslogik von der GUI will ich nicht mehr missen.
Was ich vermeiden möchte ist, für jedes Projekt von Hand neue Datenobjekte und Controler zu erstellen.

Viel lieber möchte ich ein Framework haben, in dem ich in einfacher Weise eine (auch komplexe) Datenstruktur definieren kann, Formulare zusammenklicke und beide Ebenen im Designer verbinde.
Dann ist EIGENTLICH nur noch die Geschäftslogik zu programmieren.


Ich kann anhand Eurer Diskussionen noch nicht recht nachvollziehen, wie nah oder weit wir voneinander entfernt sind. Zumindest das ANLIEGEN düfte das gleiche sein.


Im Moment habe ich keine Datenbankverbindung. Das habe ich zwar vor, aber noch keine genaue Vorstellung der Realisierung.


Vielleicht kann sich ja mal ein allgemein zugängliches Framework heraus kristallisieren, das die Arbeit mit Delphi noch weiter erleichert.
Die grundlegenden Fragen sind dabei sicher, ob die GUI leicht austauschbar sein soll und ob und in welcher Form eine Datenbank benutzt werden soll.


Grundsätzlich möchte ich anregen, bei Diskussionen nicht zu viele "wohlklingende Fachbegriffe" zu benutzen, da u.U. nicht jeder das gleiche darunter versteht...

[s.h.a.r.k]

Genau das, was Sir Rufo hier anspricht, ist grob mein Problem bie der Validierung. Denn das Model kann durchaus asynchron zur View laufen, wenn in der View falsche Daten stehen und diese somit nicht aufs Model übernommen werden. Ebenso will ich evtl. auch einen "Zurücksetzen"-Button haben, der nicht das Model neu aus der DB lädt, oder einen Abbrechen-Button, der keinerlei Änderungen der aktuellen Dialogs übernimmt. Würde ich alle Änderungen live ins Model übernehmen, habe ich dann ja mehr oder weniger Probleme... An der Stelle hat das dann nichts mehr mit Usability zu tun.

Das ist halt die Sicht der GUI-Designers. Bisher habe ich dafür noch keine gute Methode gefunden, außer die View mit den Daten aus einem Model zu füllen und dann ein neues Model für die Validierung zu erstellen, denn darin ist der Validierungs-Code bzw. die Constraints -- ob das nun in einer Validate-Methode oder in den Settern implementiert ist, ist zunächst mal egal.

[Sir Rufo]

Aber genau das geht mit DSharp. Das Bindung kann dort auch explizit erfolgen, also nur auf ausdrücklichen Wunsch.
Die Validierung bleibt aber bestehen

[s.h.a.r.k]

Hm, habe mir das mit den Bindings noch nicht so recht angeschaut. Sollte ich bei Zeit echt mal tun... Befürchte dahingehend aber irgendwie, dass mir Flexibilität bzgl. besonderer GUI-Features, wie z.B. diese Live-Validierung, verloren geht... Aber ich lasse mich gerne eines bessere belehren

[webcss]

Zitat von s.h.a.r.k:

Genau das, was Sir Rufo hier anspricht, ist grob mein Problem bie der Validierung. Denn das Model kann durchaus asynchron zur View laufen, wenn in der View falsche Daten stehen und diese somit nicht aufs Model übernommen werden. Ebenso will ich evtl. auch einen "Zurücksetzen"-Button haben, der nicht das Model neu aus der DB lädt, oder einen Abbrechen-Button, der keinerlei Änderungen der aktuellen Dialogs übernimmt. Würde ich alle Änderungen live ins Model übernehmen, habe ich dann ja mehr oder weniger Probleme... An der Stelle hat das dann nichts mehr mit Usability zu tun.

Und genau das ist der Grund für die Existenz von Pattern: Sie beschreiben lediglich in einer Art Metasprache die Lösung eines bestimmten Problems, aus der Erfahrung vieler Mannjahre heraus.

Für dieses Problem gibt es z.B. das Memento Pattern. damit erstellst Du eine exakte Arbeitskopie der zu bearbeitenden Daten -> im Model. Wenn der Controller/Presenter den Befehl erhält "Alles gut, speichern" wird diese Kopie validiert und in die Datenschicht übertragen (oder Fehler reklamiert).
Kommt der Befehl "Vergiss es, wollte nur spielen" wird die Kopie einfach gelöscht und nix passiert weiter.

[stahli]

Weil es gerade zum Thema passt: "Refactoring / Variable definieren" löst das ganz hübsch

[s.h.a.r.k]

Zitat von stahli:

Weil es gerade zum Thema passt: "Refactoring / Variable definieren" löst das ganz hübsch

Habs in Eclipse schon wesentlich schöner gesehen Sogar mit passender Fehlerbeschreibung. Unter Visual Studio kannst beim Error Insight sogar Verbesserungsvorschläge auswählen.

Zitat von webcss:

Und genau das ist der Grund für die Existenz von Pattern: Sie beschreiben lediglich in einer Art Metasprache die Lösung eines bestimmten Problems, aus der Erfahrung vieler Mannjahre heraus.

Das ist mir ja eben bewusst. Mir ist aber auch bewusst, dass ich entscheidende Dinge einfach noch nicht weiß, und ich denke, dass es hier vielen so geht. Daher habe ich den Thread eröffnet, in der Hoffnung, dass auch andere etwas davon haben Danke für den Hinweis auf das Pattern -- kannte das noch nicht

Was mir nur häufig fehlt ist eben ein konkretes Programmierbeispiel bzw. eigentlich Beispiele, da man ein Pattern ja auf mehrere Arten und Weisen interpretieren und umsetzen kann. Daher bin ich auch gerne offen für Code, über den diskutiert werden kann