Wenn alle Daten im Speicher verwaltet werden können und keine Multiuser-Zugriffe und Transaktionen nötig sind, dann ist es am einfachsten, die Daten in Objekten zu verwalten.
So lässt sich die Geschäftslogik am einfachsten umsetzen. In meinem Framework habe ich einen Klassengenerator eingesetzt, der mir die Klassen anhand einer vorgegebenen Struktur erzeugt.
Damit kann ich sehr flexibel und komfortabel arbeiten.
Die Daten werden in einer Textdatei serialisiert abgelegt und die Daten-Objekte werden beim Einlesen einer Datei neu erzeugt und gefüllt. Es sind damit natürlich keine Mehrfachzugriffe und Transaktionen möglich.
Auf keinen Fall will ich mehr auf eine Datenbindung verzichten. Egal,ob es nun im Detail mit LiveBinding, DSharp, DBControls oder mit meinen odControls erfolgt.
Jedenfalls will ich im Projekt nicht Edit.Text := Person.FirstName und Person.FirstName := Edit.Text schreiben müssen. Der Datentransport zwischen
GUI und Datenschicht soll möglichst automatisiert erfolgen.
Daraus kann man auch erkennen, dass ich
GUI und Daten künftig immer trennen will.
Passen die Daten nicht (auf jeden Fall) in den Speicher oder sind mehrfache Zugriffe oder Transaktionen erforderlich, sollte man eine Datenbank verwenden (dafür sind sie ja da).
Über einen
SQL-
DB-Server kann man Joins über mehrere Tabellen abrufen und die Daten filtern oder Mengen bearbeiten.
Der einfache Weg ist dann, DBControls zu verwenden. Man kann halt recht wenig zaubern und hat i.d.R. immer den Fokus auf einem Datensatz.
Die Geschäftslogik realisiert man über
SQL-Statements, was - ja na - auf jeden Fall umständlich ist.
Deshalb gibt es ORM-Lösungen (bekannte Beispiele sind wohl mORMot und DORM), die den Programmierer mit Objekten arbeiten lassen, die Daten aber in einer Datenbank gespeichert werden. Dann ist die Frage, wann die Daten-Objekte erzeugt werden und wie lange sie am Leben bleiben. Auf jeden Fall macht es natürlich Aufwand, die Objekte zu erzeugen und die Daten hin und her zu schaufeln. Die Frage ist auch (für mich), wie mit Versionsänderungen umgegangen wird. Was ist, wenn ich ältere Daten in meinem aktuellen Projekt öffnen will? Außerdem hat das Konzept seine Grenzen wohl bei sehr großen Datenbanken.
Wenn die Geschäftslogik sehr komplex ist und die Daten nicht übermäßig umfangreich sind, ist eine ORM-Lösung sicher sinnvoll.
Ein Databinding sollte dann auch wieder geregelt werden.
Steht die Datenbank im Vordergrund, ist ein ORM-Einsatz sicher nicht sinnvoll. Eine Bank wird ihre Konten wohl mit einer klassischen
DB-Anwendung verwenden.
Wenn schon "normale
DB-Anwendung", dann kann man überlegen, ob man einfach per Clients auf die
DB zugreift oder eine mittlere Schicht bereitstellt, die die Geschäftslogik enthält und ihrerseits auf die
DB zugreift (Multi-Tier-Anwendung). Die Clients sind dann quasi nur noch zum Anzeigen und Bearbeiten der Daten da.
Alles hat seine Vor- und Nachteile und ist mit unterschiedlichen Aufwänden verbunden.
Deshalb kann man wohl nie so einfach sagen, was man "ab besten" einsetzen soll...
Soweit mal meine Einschätzung der Sachlage.
