Moin,

ich würde den Zugriff auf meine Datenbank gerne selber regeln und daher die Daten ganz altmodisch via Select-, Insert- und Update-Statement verwalten.

Meine Frage ist nun, wie baue ich das möglichst sinnvoll auf?


Das einzige, was ich jetzt so als Idee hätte, wäre das template method pattern für Select.

Ich schreibe also eine Klasse, die irgendein Select-Statement an die Datenbank schickt und mir dann einen DataReader zurück gibt. Diese Klasse ist abstrakt und beinhaltet z.B. eine abstrakte Methode, die das SQL-Statement baut und ein Command-Objekt zurück gibt. Was besseres fällt mir nicht ein, das finde ich gut und hab es bereits auch testweise für eine Tabelle implementiert.

Für den Insert wäre vielleicht eine Option, das so zu machen, dass diese abstrakte Basis-Klasse ein Array erwartet, in dem dann Spalten-Name, Typ und der Wert, der gesetzt werden soll, enthalten sind. Und dann wieder eine abstrakte Methode, die das passende Statement zusammen baut und als Command zurück gibt.
Das wäre eine Möglichkeit, die wahrscheinlich funktionieren würde, schön finde ich die aber nicht.

Und bei dem Update fällt mir gar nichts ein, wie ich das sinnvoll umsetzen kann. Hauptsächlich es ja auch sein kann, dass sich nur ein Teil der Daten ändert. Welche Daten sich geändert haben, dass kann ich mir recht einfach mit "schreiben" lassen, aber wie setze ich dann einen solchen "Updater" sinnvoll um, ohne als Aufrufer dann die konkrete Implementierung zu kennen?



Kennt vielleicht jemand ein oder mehrere Pattern, mit denen ich diese Datenzugriffe sinnvoll regeln kann?

Ich möchte kein ORM benutzen und allgemein nicht das Entity-Framework oder Ähnliches. Ich möchte mich einfach nur im Umgang mit SQL üben.


Gruß

Palladin007 hat folgendes geschrieben :

Und bei dem Update fällt mir gar nichts ein, wie ich das sinnvoll umsetzen kann. Hauptsächlich es ja auch sein kann, dass sich nur ein Teil der Daten ändert. Welche Daten sich geändert haben, dass kann ich mir recht einfach mit "schreiben" lassen, aber wie setze ich dann einen solchen "Updater" sinnvoll um, ohne als Aufrufer dann die konkrete Implementierung zu kennen?

Also zunächst mal:
Die meisten Datenbankanbindungskomponenten machen genau das, sie setzen auch SQL-Befehle zusammen. Dort ist auch bei den allgemeinen Frameworks in der Regel ein Datentypmapping drin, das die zwischen den Datenbanken unterschiedlichen Typen korrekt behandelt.

Um den Update-Befehl zu bauen reichen, wenn vorhanden, die alten Daten der Indexspalte(n), am besten natürlich die eines Primary Key. Ist keine Indexspalte vorhanden, brauchst du alle alten Daten. Und dann schreibst du in das WHERE einfach die alten Daten rein, entweder nur die der Indexspalte(n) oder alle Daten.

Komponenten wie TClientDataSet speichern dafür alle Änderungen, bei FireDAC ist das sogar eine Art Änderungslog, so dass man schrittweise die Änderungen lokal rückgängig machen kann. Das Delta kann man bei FireDAC auch auf diverse Weisen analysieren und auch als XML wegspeichern und wieder laden.

Beim Datenhandling musst du dir überlegen wie du die Daten speicherst. Sinnvoll sind z.B. Variants, weil sich der Aufwand in Grenzen hält die unterschiedlichen Typen zu speichern. Denn als String kannst du sie z.B. schlecht speichern, einerseits wegen der unterschiedlichen Repräsentation als String für die Datenbank dahinter, andererseits weil du die Typen dann beim Auslesen aus dem String umwandeln musst.

Aber gibt es keine allgemeine Projekt-Struktur, die sich über die Jahre entwickelt hat und ausgebessert wurde?

Das ich das entsprechend umsetzen muss, ist mir klar und ein Datentyp-Mapping brauche ich auch, aber ich würde es gerne vermeiden, mir jetzt so aus dem Stegreif eine eigene Vorgehensweise auszudenken, sondern würde gerne eine bereits Vorhandene nutzen. Daher das Stichwort Pattern.


Ich hätte noch die Idee, dass das Model, was die Daten bereit stellt, INotifyPropertyChanged implementiert und die Klasse, die für den Update zuständig ist, das PropertyChanged-Event dann abonniert.
Dazu ein Attribut, das benötigte Informationen bereit stellt (Tabellen-Name, etc.).
Hat die geänderte Property dieses Attribut, wird sie in die Liste der geänderten Spalten aufgenommen, wenn nicht, wird sie ignoriert.
Für den Insert wäre das dann auch nutzbar, dass es einfach alle Propertys raus sucht, die dieses Attribut haben und dort dann alle benötigten Infos entnimmt.
Auch für den Select wäre das nutzbar und es reicht eine einzige Klasse, die das übernimmt, weil auch hier die Attribute ausreichen.

Aber das funktioniert nur, wenn ein Model wirklich nur die Daten aus einer Tabelle bereit stellt. Da das bei mir aber nicht der Fall sein wird, funktioniert das Prinzip nicht mehr.


Das Fetcher-Prinzip, was ich von der Arbeit kenne und was ich oben schon erklärt habe, ist da beim Select ganz praktisch, weil so kann ich sehr flexibel arbeiten.

Zitat:

Daher das Stichwort Pattern.

Und das Pattern heißt ORM. Wenn du kein vorhandenes benutzen willst wirst du eins nachschreiben müssen. Aber das Pattern bleibt weiterhin ORM.

Schade


Aber gut, danke für die Hilfe