Da ich mich gerade mit der Trennung von Datenhaltung und
GUI beschäftige und mir die bereits fertigen Object Persistence Frameworks zu undurchsichtig und komplex sind, habe ich mir jetzt mein eigenes kleines Framework zurecht gebastelt.
Es ist mit Sicherheit nicht so leistungsfähig, wie manches andere, aber für meine Zwecke derzeit ausreichend geeignet. Ich habe bewusst versucht, die Struktur übersichtlich zu halten, damit ich auch später noch irgendwie durchsteigen kann.
Eine kurze Übersicht:
Das grundlegende Framework besteht aus den Units
pfBusinessObjects
Basisklassen für die Erzeugung von BusinessObjects. Das sind Kollektionen, in denen die Daten zur Laufzeit gehalten werden.
pfPersistenceObjects
Basisklassen für die Erzeugung der persistenten Datenspeicherung, z.B. Datenbank, Textdokument,
XML.
pfXMLPersistenceObjects
Eine Erweiterung der pfPersistenceObjects für die Datenspeicherung in
XML-Dateien. Hierfür wird OmniXML verwendet, die Units dafür sind unter
www.omnixml.com frei downloadbar und nicht im ZIP enthalten.
Dazu gibt es noch ein kleines Beispiel, welches nicht viel kann. Es gibt zwei Business Objekte, "Projects" und "Categorys", die man hinzufügen kann, wobei die Categorys immer einem Project zugeordnet sind. Bevor man eine Kategorie hinzufügen kann, muss ein Projekt in der Liste ausgewählt werden!
pfProjects
Konkrete Implementierung des BO "Projects" und der dazu passende ProjectMapper, welcher die Datenspeicherung übernimmt. Zusätzlich wird hier ein ProjectBackend definiert, welches die Schnittstelle zur Anwendung darstellt, was die Datenspeicherung betrifft.
pfCategorys
Konkrete Implementierung der BO "Categorys" und der dazu passende CategorysMapper.
Ich stelle das ganze hier vor, weil öfter einmal die Frage nach der Trennung von Daten und
GUI gestellt wird (habe ich auch schon gemacht) und dann wenig Konkretes oder fast immer nur ein "fertiges" Framework genannt wird. Ich habe mir dies also als Beispiel gedacht, wie so etwas aussehen kann. Da ich noch keine "echte" Anwendung damit realisiert habe (wobei ich nur im Hobbybereich tätig bin), kann ich noch nichts darüber aussagen, wie "gut" das in der Praxis funktioniert.
Noch eine kleine Anmerkung: Ein Vorteil der Datenhaltung in BO ist, dass man, sobald man die BO hat (noch ohne Mapper oder Backend), bereits munter seine
GUI programmieren kann. Die Daten können halt nicht gespeichert werden, das ist alles. Wie die Daten später gespeichert werden (oder vielleicht auch auf unterschiedlichen Arten) kann später immer noch festgelegt werden ohne an der
GUI etwas ändern zu müssen.
Auf den ersten Blick erscheint das Alles evtl. etwas verwirrend, aber in der Umsetzung muss man die ersten drei erwähnten Units nicht mehr anschauen. Nur die Erstellung der BO und der Mapper sind wichtig. In der
GUI reduziert sich der Aufwand noch einmal entsprechend, da man nur noch auf die BO zugreift.
Mein letztes Wort: Vermutlich gibt es noch einige Fehler, z.B. habe ich das Löschen von Items aus dem BO noch gar nicht probiert und wie die Umsetzung eines pfADOPersistenceObjects aussehen könnte...?