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