Einfaches Persistence Framework

[guidok]

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

[mjustin]

Für die Bindung an die GUI ist eventuell "Snap Object Dataset" brauchbar, damit kann ein Objekt in ein DataSet gepackt und dann mit datensensitiven Steuerelementen editiert werden, also wieder Delphi RAD möglich wird:

http://www.torry.net/pages.php?s=124

Ansonsten sind die verfügbaren ORMs nicht schlecht, aber ich tippe, dass mit den neuen Sprachmöglichkeiten von Delphi 2009 (Generics vro allem) sich hier bald etwas tun wird.