@DJ-SPM
Du gehst genau in die gleiche Richtung, wie ich auch.
In Deinem letzten Thread hatte ich schon auf 2 Themen gelinkt, die auch mit in den Bereich fallen.
Bisher habe ich es so gelöst, dass ich Datenobjekte und eine Eigenschaft an ein sichtbares Control binde (odControls).
Wenn das Control sich zeichnet liest es seinen darzustellenden Wert aus der Objekteigenschaft (z.B. Person.FirstName). Das funktioniert mit der erweiterten
RTTI ab D2010 einfacher.
Das Framework kümmert sich auch darum, die sichtbaren Controls zu informieren, wenn ein gebundes Datenobjekt aufgelöst wird.
Die Formulare erhalten einen "odFormControler" (der wird einfach auf das Formular gesetzt), der die Verbindung der Datenschuicht und
GUI übernimmt.
Insofern ist das alles soweit automatisiert. Man stellt einfach zur Designzeit die gewünschten Eigenschaften ein und das Framework erledigt den Rest.
Das funktioniert so aber nur, wenn alle (Daten-)Objekte die ganze Zeit im Hauptspeicher gehalten werden. Auch müssen sich die Datenklassen untereinander zum großen Teil kennen, und davon will ich künftig gern weg kommen.
Daher plane ich für später eine Lösung in der Art:
- Controls wird eine Id zugewiesen
- die Controls fordern von einem Broker Schnittstellen ab (anhand der Id)
- der Broker erzeugt/verwaltet/zertstört die Objekte und gibt auf Anfrage Schnittstellen heraus
- dabei kann der Broker auf einen ORM zurück greifen - oder auch nicht
- bei Bedarf kann der Zugriff über C/S realisiert werden
Auf jeden Fall würde ich künftig Controls nicht mehr fest an Datenobjekte binden wollen. Besser (übersichtlicher) ist es wohl, nur Id´s zuzuweisen und die Objekte bei jedem Zugriff neu abzufragen. Der Broker wäre dann dafür zuständig, die Objekte in sinnvoller Form zu cachen.
Ich hatte schon länger mal geplant, bzw. mir gewünscht, dass die
DP-Profis mal gemeinsam ein entsprechendes Demoprojekt aufbauen, damit man als Einsteiger mal einen Zugang dazu findet. Wer wäre dabei? Man könnte mal ein paar Kriterien zusammenstellen...