Hallo,
ich überlege derzeit, ein größeres Programm in eine echte Client-/Server-Architektur einzubauen. Das Programm besteht aus einem Hauptprogramm mit mehreren Modulen/Plugins. Die Datenspeicherung übernimmt eine
MySQL-Datenbank.
Da das Programm und dessen Plugins hauptsächlich mit Daten aus der
DB arbeiten, benötigt jedes Programmteil eine Datenbankverbindung und muss mit dem
DB-Server kommunizieren können.
Das hat natürlich zum Nachteil, dass pro Benutzer mehrere Datenbankverbindungen (eine pro Programmteil) geöffnet wird. Weiterer Nachteil ist, dass es zu schwer abfangbaren Problemen im Programm kommt (keine Reaktion etc.), wenn die Verbidung zur Datenbank verloren geht. Dies kann durch remote-Zugriff via VPN etc. öfter mal passieren.
Daher habe ich mir überlegt, einen Windows-Dienst zu schreiben. Dieser läuft auf dem Windows-Server 24/7. Programme/Plugins können bauen eine
TCP-Verbindung zum Dienst auf, senden ihm ein command (zB getTasks), der Dienst verbindet sich zur Datenbank, liest die Daten aus und sendet sie per
tcp (hier meine ich
Indy-
TCP-Server/Client) an den Clientprozess zurück. Wenn keine Internetverbindung besteht, kann man das echt gut abfangen und es wäre immer nur eine Datenbankverbindung (nämlich Dienst <-> Datenbank) geöffnet. Alle Datenbankoperationen (hinzufügen, ändern, löschen) würden dann vom Dienst übernommen werden. Dies ist auch einfacher zu Warten.
Die Kommunikation zwischen Client und Dienst würde per Strings/Records stattfinden. Da wir
OOP nutzen, würden die Daten eines Objekts in ein Record übergeben und dann zum Dienst übertragen werden, da man ja keine Objekte verschicken kann. Oder, wenn es in Delphi auch sowas gibt, dann ein serialisiertes Objekt (ähnlich zu json_encode in php).
Macht man das so? Was haltet ihr davon? Habt ihr Tipps dazu?
Danke im Voraus