Einzelnen Beitrag anzeigen

cytrinox

Registriert seit: 4. Sep 2006
88 Beiträge
 
#1

DataSnap, dbexpress und Einzelplatz/Netzwerklösungen mit XE2

  Alt 28. Dez 2011, 13:09
Hi,

da nun nach einigen Jahren die Portierung einer alten (großen) Delphi-Anwendung auf Delphi XE2 ansteht, habe ich mir Features wie DataSnap, DBExpress usw. einmal genauer angesehen. Zuerst etwas zur Theorie:

Die Anwendung besteht aus 3 Komponenten: Client, Server und Datenbank (z.B. MS-SQL oder Firebird).
Meine Überlegung zur Architektur war bisher wie folgt:

Der Server läuft als Windows-Dienst. Der Client stellt mittels Datasnap eine TCP/IP Verbindung zu eben diesem Server her. Datenbankverbindungen werden vom Server aufgebaut (d.h. DB-Client Libraries wie z.B. fbclient.dll oder sqlncli werden NUR auf dem Serversystem installiert) und die Clients arbeiten mit der Datenbank ausschließlich über die Datasnap-Verbindung zum Dienst.

Dazu nun folgende Fragen/Probleme:

Ich habe öfters gelesen, dass nicht die Connection per Datasnap an die Clients getunnelt werden (und auf Client-Seite dann ein TDatasetProvider, TClientDataset, ...) sondern auf Serverseite ein TDatasetProvider bereitgestellt wird, und nur der Provider an den Client weitergereicht wird (d.h. auf Clientseite nur ein TClientDataset).
Hat dies irgendwelche Vorteile, z.B. bezüglich der Geschwindigkeit/Traffic? Ich würde es vorziehen nur eine zentrale Connection auf Serverseite zu haben und die Provider auf Clientseite, wenn nichts dagegen spricht (Hauptsächlich weil es kaum Logik gibt die serverseitig implementiert werden müsste, d.h. wird eine neue Tabelle/Bereich eingebaut, müssten sowohl der Client als auch der Dienst angepasst werden, was ich gern vermeiden möchte).

Der Server soll ein paar einfache Methoden für die Clients bereitstellen, um z.B. Konfigurationsparameter abzurufen. Das ließe sich da über einen Datasnap Server sehr einfach lösen. Allerdings ist mir das mit der Lifecycle nicht nicht klar. Angenommen ich wähle "Server", dann existiert ja nur eine Instanz, auf die aber von mehreren Clients/Connections zugegriffen wird. Kümmert sich Datasnap da schon um's Locking oder muss ich die Klasse thread-safe bauen?

Mehrfach steht im Docwiki, dass diese ganze DataSnap/RemoteMethod Sache irgendwo über ein IAppServer Interface läuft, bzw. Klassen die dieses Interface implementieren auch um Methoden ergänzt werden können, die Clients widerum aufrufen. Ich habe über diesen Datasnap Expert mal anhand des Tutorials so ein Mini-Server & Client gebaut, aber ich konnte im Code (und den verwendeten Basisklassen) nichts finden, was IAppServer implementiert. Wo steckt das genau, und wird unterschieden zwischen Methoden die per TDSServerClass bereitgestellt werden (da muss ich für den Client-Code ja noch den passenden Code erzeugen -> "Generate Datasnap Client classes") und zwischen Methoden die über IAppServer bereitgestellt werden? Wie können diese dann überhaupt vom Client aufgerufen werden?

Angenommen ich nehme die Variante bei der lediglich eine TSQLConnection serverseitig erstellt wird und die Clients diese per Datasnap mitbenutzen, dann schätze ich mal muss ich pro Session eine Connection erzeugen. Zumindest habe ich das so unter http://www.andreanolanusse.com/en/sh...erver-modules/ verstanden. Müsste dann aber nicht auch Dinge wie TDatasetProvider usw. pro Session erstellt werden? Sonst hab ich da vielleicht 10 Clients, die alle gerade (serverseitig) den "tblArtikelProvider" nutzen wollen?!

Abschließend noch die Frage, ob es möglich ist den Datasnap Server als Einzelplatz Lösung "im" Client laufen zu lassen (z.B. den DataSnap Server in ein BPL Modul auslagern, was bei einer Einzelplatzversion per Compilerschalter mit eingebaut wird). Dabei würde auch nur eine embedded Firebird-Datenbank zum Einsatz kommen.



Gruß
Daniel

Geändert von cytrinox (28. Dez 2011 um 13:13 Uhr) Grund: Korrekturen
  Mit Zitat antworten Zitat