Theoretische Frage zum Thema Middleware

[ice.icewing]

Theoretische Frage zum Thema Middleware.

Ich habe ein fertiges und funktionierendes Programm an dem ich nur ungern größere Änderungen vornehmen möchte. Dieses Programm nutzt ein propritäres DBMS für seine Daten. (kein SQL)

Frage: Ist es a) Möglich und b) Sinnvoll eine Software zu schreiben die unterhalb der Anwendung sitzt und als Middleware zwischen der Anwendung und einer SQL-Datenbank agiert.

Wenn es möglich ist stellt sich die Frage, wie komme ich an das ran was an Anfragen aus der Anwendung raus kommt und wie Bekomme ich eine Anwort wieder in das Programm zurück.
Im Grunde wie Emuliere ich für die Bestehende Anwendung ihre gewohnte Datenbank.

Ich hoffe ich kann hier ein paar Denkanstöße bekommen, oder aber ein klares „das ist keine gute Idee“ worauf hin ich über andere Lösungswege nachdenken müsste. Ich bin auch für Alternative Lösungsvorschläge offen.

Gruß icewing

[mkinzler]

Wie erfolgt die Einbindunge der prop. DB? Als Dll? Dann wäre das ja der Ansatz.

[ice.icewing]

Leider nein.

Ich habe die Sache in ihrer komplexität noch nicht ganz erfasst, aber hier werden Delphikomponenten wie TDataSourge zusammen mit Komponenten von Drittanbietern genutzt. Gefunden habe ich da TDBISamTable, TDBISamQuery und TDBISamSession. Wobei ich mir fast sicher bin, dass das noch nicht alles ist.

icewing

[QuickAndDirty]

Also wir steigen von BDE auf Dbisam und DBExpress um.
Dazu habe ich uns ein eigenes Dataset geschrieben welches
über eine DLL auf die Datenbankzugreift. Es ist noch nicht ganz fertig aber
es wird so sein das man am Ende nur noch eine neue DLL schreiben muss die zwischen
meinem TDataset und einer xbeliebigen Datenbank steht,
wenn ein Umstieg gemacht werden muss.

Wenn du nur eine kleine Anwendung hast würde ich dir Raten oberfläche(View) und Logik(Controller)
in getrennte Programme zu Packen also einen ApllicationClient und einen ApplicationServer die Kommunikation
machst du dann über TCP/IP dann. So brauchst du nicht so viel Code umstellen.

[ice.icewing]

Ich habe gründlich über dein Lösungsvorschlag nachgedacht und das könnte funktionieren. Dennoch ist es (sehr) viel Arbeit. Leider ist die Anwendung alles andere als klein. Daher wollte ich ja eigentlich nicht groß am Quelltext ändern.
Problem: Es gibt in den genutzten Komponenten recht viel das einfach public ist eine Schnittstelle kann man das dann schon nicht mehr nennen. So ganz wohl ich mich also nicht mit der Umarbeitung auf eine dll zu beginnen. Wenn ich fragen darf wie viel Zeit ist in das DataSet investiert wurden bevor man sagen konnte man hat ein vorzeigbares (wenn auch noch nicht entgültiges) Ergebnis?

Ein Punkt fehlt mir allerdings noch. Soll ich die Methoden der jetzigen Komponenten durch welche mit gleichen Namen und gleichen Parametern ersetzten die in die dll führen, wo ich dann fürs erste wieder den Orginalquelltext rein bringe, aber dann die Möglichkeit habe die dll und damit den Quelltext zu ersetzten. Oder den ganzen langen Quelltext des Hauptprogrammes durchgehen und die Aufrufe an den jeweiligen stellen auf die dll umleiten.

icewing

[QuickAndDirty]

Es hat einiges an Zeit gedauert, weil ich auch ein paar Sackgassen hatte und weil ich jede
Menge, mittlerweile unnötigen Code erzeugt habe. Das ist ausserdem mein erstes eigenes Dataset.

Zusätzlich habe ich auch Dummy Klassen TSession und Tdatabase enwerfen müssen. Diese jedoch sind relativ einfach
Sie schleifen einfach die Methoden zu Dll Prozeduren durch und Sie funktionieren.

Das TDataset jedoch ist leider nicht so realisierbar, daß Methoden einfach an die DLL weitergereicht werden.
TDataset macht bereits einige Sachen selbst. Diese Geschichten sind oft privat und mit dem Datasource/Datalink Modell aus der DB Unit verschränkt.
Du must also einen ganzen TDataset Nachfahren wie TTable einer ist nachbauen. Der Datenzugriff erfolgt dann halt in der DLL über
ein TTable Object oder ein TDBIsamTable oder oder oder.

Führ Dir das mal zu Gemüte
http://WWW.gexperts.com/CustomDS.Html
da sind auch brauchbare Sourcen dabei

Die Buffer der Sourcen die er da liefert must du erweitern, weil sie keinen NULL Wert unterstützen und deshalb
für Datenbanken etwas blöd sind. Aber da ist sowieso ne Menge zu tun.

Für das DLL ist es Sinnvoll es dynamisch zu importieren so
das man auch auf mehreren Datenbanken mit einer Anwendung arbeiten kann.

Es ist sinnvoll wenn du die Sourcen von der Datenbank hast die du auf der DLL Seite benutzt.