Datenbankzugriff in DLL auslagern?

[Peter1981]

Hallo,

ich möchte ein Programm schreiben, bei dem der eigentliche Zugriff auf die Datenbank möglichst ausgelagert ist. Meine Grundidee ist, dass das Programm nur eine Funktion, z.B. AddUser, aufrufen soll, welche dann an eine entsprechende DLL delegiert wird, in welcher dann der Datenbankzugriff stattfindet. Damit könnte ich dann z.B. eine DLL für die Benutzung von Access, eine für MySQL usw. schreiben. Umgesetzt habe ich dies momentan versuchsweise mit einem COM-Server.
Meine Frage an euch: Ist dies ein halbwegs brauchbarer Ansatz oder gibts es elegantere Verfahren, um die gewünschte Flexibilität der Datenbankanbindung zu realisieren?

Schon einmal danke für die Antworten,

Peter

[Bernhard Geyer]

COM einzubinden halte ich für oversized. Sowas kann man mittels Bridge-Pattern auch in eine Exe integrieren.

[hoika]

Hallo,

ich nehme mal an, die AddUser sieht unter Access etwa so aus

Delphi-Quellcode:

var
  conn: Connection;
  ds: TDataSet;
begin
 ...
  conn.Connected:= True;
 ...
  ds.Insert;
 ...
  conn.Connected:= False
end;

D.h., bei jedem DB-Aufruf muss die Connection neu aufgebaut werden.

Performance-mäßig wohl ein Grauen (wenn man keinen Connection-Pool hat).

Ich würde entweder
1. abstrakte DB-Klasse
function AddUser(): Boolean virtual; abstract;
pro DB eine Ableitung

2. interfaces

benutzen

Ich würde 1. benutzen
Interfaces gefallen mir unter Delphi überhaupt nicht wegen diesem COM drumrum


Heiko

[Elvis]

Um State halten zu können, sollte das Ganze schon bbject-Orient, und nicht nur plattgedrückte C-kompatible exportierte Funktionen, sein (Sonst gibt es das Problem, was Hoika ansprache, dass zu oft Verbidnungen geöffnet/geschlossen werden).
Aber wie ich in letzter Zeit immer und immer wieder geschrieben habe, lässt sich das mit Interfaces ganz gut lösen, gänzlich ohne COM.
Gerade bei Datenbankschnittstellen könnte man so Teile der Logik zum Beispiel in .Net schreiben und dadurch auch Zugriff auf die unzähligen kostenlosen DataProvider bekommen.

Du überlegst dir also was du tatsächlich auslagern musst, und das verpackst du dann in ein paar Interfaces.
Die PlugIns registrieren dann solche "Datenzugriffsstrategien", wodurch deine App plötzlich ihre Daten aus verschiedenste Quellen aggregieren könnte.

[Bernhard Geyer]

Zitat von hoika:

Interfaces gefallen mir unter Delphi überhaupt nicht wegen diesem COM drumrum

Mann kann auch Interfaces verwenden ohne COM. Wenn man die 1-2 möglichen Fallen vermeidet hat man hier auch sowas wie "Garbage Collection"

[Peter1981]

Ich glaube, so in der Art hatte ich das hier auch realisiert. Ich hab zwar den Assistenten für COM verwendet (Delphi 5), am Ende bestand dies aber nur aus der Projektdatei mit den zu exportieren Funktionieren und einer Unit, in der die realisierende Klasse definiert war. Zumindest hatte ich in diesem Beispiel keine TLB erstellt oder gar den COM-Server registriert, einfach DLL per LoadLibrary laden, Einsprungadresse der Funktion suchen und fertig.
Momentan versuche ich die Variante mit dem Bridge Pattern, das wäre auch ne Möglichkeit.

[mjustin]

Zitat von Peter1981:

Meine Frage an euch: Ist dies ein halbwegs brauchbarer Ansatz oder gibts es elegantere Verfahren, um die gewünschte Flexibilität der Datenbankanbindung zu realisieren?

O/R Mapper verwenden:

* hcOPF
* tiOPF
* InstantObjects

(alle Open Source)

Diese können dann für Zugriff auf diverse Datenbanken (z.B. auch XML) konfiguriert werden, ohne dass Code in der Anwendung geändert werden muss. Vorbilder dieser Mapper sind Hibernate, NHibernate, ECO, Bold, EclipseLink, die alle sehr populär sind.

Viele Grüße,

[Elvis]

Zitat von mjustin:

O/R Mapper verwenden

Ist schon ewig her, dass ich mir Delphi ORMs angesehen habe, aber wa sich damals sah war schon sehr frickelig.
Wenn das nicht mehr der Fall war, oder ich mich beim Evaluieren damals zu sehr auf das verbohrt habe, was ich aus .Net kannte, dann wäre ein ORM natürlich das Mittel der Wahl!

[Peter1981]

Mit InstantObjects hatte ich zumindest schonmal eine Demo zusammengestellt, ging an sich recht einfach. Bei tiOPF häng ich noch in der Anleitung fest, da komm ich demnächst hoffentlich mal weiter. Gibt es speziell für tiOPF gute Tutorials?

[MyRealName]

Ich nutze Datenbank funktionen in einer DLL ohne Probleme. Was genau Du alles einbinden musst, hängt von deiner Datenbank-Componente ab.
Auch solltest Du Transaktionen und das Datenbank-Objekt selbst in der DLL haben, um es wirklich austauschbar zu machen. Ein beispiel mit Source kannst Du Dir ja bei mir auf der Seite runterladen (unter Downloads das Projekt TCA www.maf-components.com). In der Projektgruppe ist ein DLL Projekt namens RouterFileDB.dll, welches eine kleine selbstgeschriebene File-Datenbank nutzt, aber es liegen dort noch mehr Projekte für andere Zugriffsarten (Firebird/Interbase, MySQL, MSSQL). Ich nutze dazu eine selbstgeschriebene Bridge-Komponente, die den jeweiligen DAC (DataAccessComponent) mit meinen Komponenten verbindet. Dadurch kann ich durch einfaches Austauschen der Router.dll die benutze Datenbank dahinter austauschen.