Da jedes Datenbank-System sein eigenes Süppchen kocht (Datum, Boolean, Texte, etc.) und auch die Verbindungen das immer etwas anders interpretieren, würde ich empfehlen die Anwendungs- bzw. UI-Schicht nicht direkt mit der Datenbank zu verbinden.
"Einfach" die Daten für die Anwendungs-Schicht in Klassen (Model) zusammenfassen, für die UI-Schicht anderen Klassen (ViewModel) und für den Austausch mit der Daten-Schicht ein DTO (DataTransferObjekt) inkl. Assembler (Model <-> DTO).
Ist zugegebenermassen mehr Aufwand als einfach eine
Query hinklatschen und mit LiveBinding zu verbinden, dafür hat man aber alles in der Hand und jede Menge Spielraum für die Implementierung ohne sich ständig ins Knie zu schießen.
Das ist ein Thema, dass mich sehr interessiert (eigentlich müsste man dazu mal einen eigenen Thread aufmachen). Spätestens wenn man Crosscompile-Projekte macht, merkt man, wie wichtig es ist, Oberfläche und Datenschicht / Anwendungslogik zu trennen.
Was Du hier ansprichst, geht ja auch noch einen Schritt weiter, nämlich die Verarbeitung der Datenschicht austauschbar machen (sorry, wenn ich als Jurist und Teilzeit-Entwickler nicht immer die richtige IT-Terminologie treffe).
Ich musste mir mal ein größeres Geschäft durch die Lappen gehen lassen, weil ein Interessent zwar an meinem Adressprogramm sehr interessiert war, er wollte aber als Datenbank ein bestimmtes Format haben und
SQL-Abfragen sollten möglich sein. Da musste ich leider passen.
Insofern wäre es Klasse, wenn man das Programm so umschreiben könnte, dass man die Daten von frei wählbaren Datenbank-Engines verwalten lassen könnte. Bei im Übrigen gleicher Oberfläche bzw. leichten Anpassungen an erweiterten Fähigkeiten der jeweiligen Datenbank-Engine.
Nun, da ich ja leider (noch) keine Ahnung von der klassischen Datenbankprogrammierung habe (also die Sachen, die Delphi so anbietet), meine Frage, ob es hierzu entweder Literatur oder Demo-Beispiele gibt, wo einmal demonstriert wird, wie man das von Dir beschriebene Modell implementiert?