Delphi-PRAXiS
Seite 1 von 10  1 23     Letzte » 

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Client/Server Architektur realisieren - Ideen (https://www.delphipraxis.net/183029-client-server-architektur-realisieren-ideen.html)

TheMiller 5. Dez 2014 12:55


Client/Server Architektur realisieren - Ideen
 
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

Dejan Vu 5. Dez 2014 13:19

AW: Client/Server Architektur realisieren - Ideen
 
Früher konnte man das noch direkt mit Delphi-Bordmitteln lösen, jetzt sollte das doch auch noch gehen. Stichwort: TRemoteDatamodule

Es gibt auch Drittanbieter, die das noch 1000x besser gelöst haben (RemObjects)

Erfinde das Rad nicht neu.

Der schöne Günther 5. Dez 2014 13:20

AW: Client/Server Architektur realisieren - Ideen
 
Schau doch mal nach wann die erste JSON-Serialisierung in Delphi kam. War es nicht sogar 2009 oder 2010?

Olli73 5. Dez 2014 13:37

AW: Client/Server Architektur realisieren - Ideen
 
Zitat:

Zitat von DJ-SPM (Beitrag 1282355)
ich überlege derzeit, ein größeres Programm in eine echte Client-/Server-Architektur einzubauen.

Wenn du jetzt schon einen DB-Server einsetzt ist das doch bereits eine Client/Server-Anwendung; was du vorhast, wäre dann eine Multi Tier Architektur, oder liege ich da falsch?

Zitat:

Zitat von DJ-SPM (Beitrag 1282355)
und es wäre immer nur eine Datenbankverbindung (nämlich Dienst <-> Datenbank) geöffnet.

Dann (mit 1 Datenbankverbindung) kannst du allerdings i.d.R. die Abfragen nur nacheinander ausführen. Das heißt, wenn ein Client eine Abfrage schickt, die z.B. 20 Sekunden benötigt, müssen alle anderen warten. Daher sollte man das "Multi Threaded" lösen und dazu brauchst du i.d.R. wieder mehrere Datenbankverbindungen, was aber auch nicht schlimm ist.

Gruß,
Olli

TheMiller 5. Dez 2014 13:46

AW: Client/Server Architektur realisieren - Ideen
 
Danke für die Antworten.

Mutil Tier habe ich zwar schon öfter gelesen, mich aber nie darum gekümmert, was es ist.

Die Datenbank läuft i.d.R auf einem Linux-Server (MySQL).

Es ist richtig, dass die Verarbeitung dann nacheinander durchgeführt wird. Man könnte ja überlegen, die Anzahl der offenen Verbindungen auf 2 Stk. pro User zu beschränken. Immernoch besser, als wenn jedes Plugin eine offene Verbindung hält. Manchmal sind nämlich gleichzeitig 4 Plugins offen. Das macht bei 10 Usern - die die Anwendung regelmäßig nutzen - 40 Verbindungen. Ich dachte, es wäre besser, dies zu reduzieren und das alles zentral abwickeln zu lassen.

Der Dienst soll darüber hinaus noch andere zentrale Aufgaben übernehmen, die nichts mit der Datenbank zu tun haben.

Wichtig wäre mir halt auch das Abfangen auftretender Verbindungsprobleme, was über einen Dienst mit Kommunikation zum Client besser gehandlet werden könnte. Denke ich.

Ich habe ein wenig über TRemoteDatamodule gelesen. Verstehe das alles noch nicht so ganz. Wüsste aber auch nicht, wo die Vorteile sind. Wenn ich dem Indy-TCP-Server einen Command schicke, weiß er, was damit zu tun ist, läd die Daten aus der Datenbank (dazu nutze ich übrigens UniDAC), und gibt das json zurück via Indy-TCP. Geht es wirklich noch einfacher, oder habe ich einen Denkfehler?

Ihr seht - das ist noch neu für mich.

TheMiller 5. Dez 2014 13:50

AW: Client/Server Architektur realisieren - Ideen
 
Ein kleiner Nachtrag noch, warum ich diese Architektur in Erwägung ziehe. Bin aber dahingehend für alles offen ;)

Der Server könnte so auch alle Clients mit aktivem Modul XY benachrichtigen, wenn sich Änderungen in ihm bzw. dem Datenbestand ergeben haben.

So könnten die Clients gleich die neuen Daten laden.

Sir Rufo 5. Dez 2014 13:53

AW: Client/Server Architektur realisieren - Ideen
 
Wenn der Datenbank Server schon auf einer Linux-Kiste läuft, dann klatscht dir da mit PHP ein REST drauf und lass das darüber laufen. Dann brauchst du auf den Clients auch keine Datenbank-Treiber mehr, nur noch HTTP-Abfragen ausführen :)

TheMiller 5. Dez 2014 13:57

AW: Client/Server Architektur realisieren - Ideen
 
Genau das habe ich mir auch schon überlegt.

Nur leider soll der Dienst ja auch weitere, nicht-datenbankbezogene Aufgaben erledigen. Wie ich eben oben schrieb, soll er ja auch Nachrichten an die Clients schicken, wenn sich ein Datenbestand geändert hat, der gerade via Plugin von einem Client offen ist.

Auch soll sich der Dienst über die Benutzerverwaltung kümmern (wer ist mit welcher IP online, wer ist offline), kleiner Chat, Backup und einige weitere Funktionen aus dem Bereich der Textverarbeitung der Clients etc.

fillibuster 5. Dez 2014 13:58

AW: Client/Server Architektur realisieren - Ideen
 
Hi,
Zitat:

Zitat von Sir Rufo (Beitrag 1282366)
Wenn der Datenbank Server schon auf einer Linux-Kiste läuft, dann klatscht dir da mit PHP ein REST drauf und lass das darüber laufen. Dann brauchst du auf den Clients auch keine Datenbank-Treiber mehr, nur noch HTTP-Abfragen ausführen :)

... und hier das passende PHP Framework dazu: http://www.slimframework.com/. Habe ich genau für diesen Anwendungsfall sehr gute Erfahrungen mit gemacht.

Viele Grüße ....

TheMiller 5. Dez 2014 14:04

AW: Client/Server Architektur realisieren - Ideen
 
Die Datenbankkommunikation könnten wir aber tatsächlich in eine PHP-Anwendung auslagern, da wir - zumindest Teilfunktionen - auch für andere Plattformen wie (na klar) iOS etc. planen. Da müsste man nur eine Stelle pflegen.

Dennoch bleiben die anderen Aufgaben übrig und die Benachrichtigung über neue Daten würde wieder schwerer zu realisieren sein. Ein Timer-Polling der Clients will ich eigentlich vermeiden.

Würde gerne so programmieren, dass man auch locker von außerhalb via VPN arbeiten kann, ohne, dass alles brechend langsam wird.


Alle Zeitangaben in WEZ +1. Es ist jetzt 12:51 Uhr.
Seite 1 von 10  1 23     Letzte » 

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz