RemObjects Data Abstract, Schema Modeler erzeugt alles auf dem Client

[Kostas]

Hallo Zusammen,

ich habe nach Doku ein neues Projekt erzeugt mit einem Server und einem Client.
Dem Data Modeler habe ich eine große Datenbank gegeben und er hat für jede Tabelle
ein TDAMemDataTable, TDADataSource, TDASpiderMonkeyScriptProvider erzeugt, allerdingt
auf dem Client-Projekt fClientDataModule.pas eigentlich erwarte ich das auf dem Server.
Serverseitig hat er jedoch nichts angelegt. Der Server ist doch zuständig für Daten.
Der Client kann durchaus mit nur einer Untermenge des Schemas arbeitet.(Mobile Anwendung)
Ich hoffe, ich habe etwas falsch gemacht!

Gruß Kostas

[kretabiker]

Hallo Kostas,

Deine Frage ist schon ein paar Tage her - ist sie noch aktuell?

[Kostas]

Ja, sehr aktuell.
Danke der Nachfrage.

[Edit]

Ich habe wichte Sache nich nicht verstanden.

Thema: Business Logik von Client in den Server verlagern(thin clients).
Wenn ein Projekt Custom Server und Client per Wizard erstellt wird, ist auf der Serverseite der Schema Modeler
der alle Tabellen, Views, StoredProcs u.s.w. abstrahiert. Serverseitig werden keine MemDataTable erzeugt.
Dafür werden sie auf dem Client erzeugt. Eigentlich ist der Gedanke der, dass der Client so wenig wie Möglich
Logik enthält und alles der Server erledigt. Serverseitig benötige ich den vollen Zugriff auf die Datenbank.
Über welche Komponenten greife ich Serverseitig auf die Daten zu und wie werden die Resultate zum Client übertragen?

Die Clients greifen über den RemoteDataAdapter + MemDataTable auf das Element "Table" zu. Das würde jedoch bedeuten dass
die Business Logik doch am Client ausgeführt wird. Oder ist mit Client hier nicht die Clientapplication für den Endanwender
gemeint sondern der Application Server? Also ((Data Abstact Layer) <<>> (Application Server) <<>> (Thin Client)) Meine Vorstellung ist
dass ((Data Abstact Layer) und (Application Server)) als ein Service laufen und die (Thin Client) sind Windows Forms Anwendungen für den User.

Ober habe ich komplett alles mistverstanden?

Gruß Kostas

[kretabiker]

Hallo Kostas,

was der Experte erzeugt, ist ein Grundgerüst eine Standard-Multitier-RoDa-Sonstwas-Anwendung, um den Einstieg zu erleichtern.

Um Businesslogik - und damit meine ich nicht allein Datenbankzugriffe, sondern auch echte Verarbeitungslogik - in den Server zu verlagern, gehe ich in Grundzügen so vor (ich beschreibe die Schritte mal von Anfang an, da ich nicht weiß, wie es bei dir genau aussieht):

- Im Service-Builder des RODA-Servers einen neuen Service anlegen mit Anchestor DataAbstractService
- Im neuen (oder einem bestehenden) Service dann eine neue Operation erzeugen und parametrisieren (In-/Out-Variablen, Rückgabewert)

Das ist die Schnittstelle, die du später im Client aufrufst.

Nach dem Speichern wird dir für jeden definierten Service eine Reihe von Dateien erzeugt, unter anderem eine mit dem Postfix "_Impl.pas". Das ist die Datei, in der du mit dem Implementieren beginnst. In dieser Datei befinden sich dann automatisch zwei Komponenten: Einmal der DataStreamer, einmal das TDASchema. In dieser Schema-Komponente werden die Datenbankverbindungen bzw. die Zugriffsgeschichten zur Datenbank erzeugt und gepflegt - wenn ich dich richtig verstanden habe, hast du das bereits.

Um jetzt mit dem Datenbankschema direkt im Server arbeiten zu können, KANNST du die Vorgehensweise des Clients quasi kopieren:
- Ziehe dir eine Komponente des Typs TDALocalDataAdapter auf die _Impl-Datei und setze das Property "ServiceName" auf den gewünschten Service
- Rechtsklick auf den DataAdapter bringt ein lokales Menü, in dem du wie im Client nun mit "Create data tables" die gewünschten TDAMemDataTables erzeugst

Jetzt stehen dir die Datentabellen serverlokal zur Verfügung zur weiteren Bearbeitung.

Weiter geht es mit der Implementierung:
- Im Code der _Impl-Datei findet sich für jede im Service definierte Operation im Interface-Teil eine entsprechende Methode mit allen Parametern. Dies ist der Startpunkt für deine echte Implementierung der Businesslogik.
- Auf die TDAMemDatasets greifst du wie im Client über den Namen zu und arbeitest wie mit Datasets (Editieren, Löschen, Einfügen, Locate usw.)
- Auch das Einschränken der Ergebnismenge mit DynamicWhere funktioniert exakt wie auf dem Client

- Du kannst auch - zumindest lesend - auf Tabellen des Schemas zugreifen, für die du keine TDAMemDatasets angelegt hast; das machst du dynamisch z.B. über eine solche Codesequenz:

Delphi-Quellcode:

var
  dsBasisEin: IDADataset;
  ISEConnectionName: string;
begin
  ISEConnectionName := Session.Values[sess_ISEConnectionName];
  Connection := ISEPricingSchema.ConnectionManager.NewConnection(ISEConnectionName);

  Connection.BeginTransaction;
  try
    dsBasisEin := ISEPricingSchema.NewDataset(Connection, 'BasisEin', [], []);

    dsBasisEin.ParamByName('AdressID').AsInteger := AHotelID;

    dsBasisEin.Open;

Ob und wie man sowas dynamisches auch für eine beschreibare Tabelle verwenden kann, habe ich nicht weiter erforscht, aber im IDataSet fehlen elementare Dinge eines DataSets - vielleicht hilft ein Cast auf den passenden Datentyp oder so.

Wenn deine Businesslogik nun fertig ist (an Threadsicherheit denken!), brauchst du noch den Aufruf im Client. Das kann z.B. so aussehen:

Result := (ISEPricingService as IISEPricing).GenerateCatalogPricesHotel(APeriode.ID, AHotelID, DaysOfWeek, ARoomRateID, DaysOfStay, ServiceIDs); Also Typcast des im Client-Datamodule erzeugten TRORemoteService zum gewünschten Service und danach Aufruf der serverseitig im Service deklarierten Operation und deren Parametern.

Das war es in Grundzügen. Jetzt können (müssen aber nicht explizit) Businessprozessoren usw. ins Spiel, aber das hängt von deiner Anwendung ab.

Stichwort Fehlersuche/Debugging: Aus leidiger Erfahrung rate ich dir, zunächst im Server nur ein Dummy der Operation zu implementieren, die dir genau definierte Werte zurückliefert und dann zunächst den Client zu bauen, bis der damit funktioniert. Erst danach würde ich den Server Stück für Stück aufbauen - dann kannst du den Server im Debugger laufen lassen und die Anfragen über einen seperat gestarteten Client absetzen - ansonsten suchst du dich tot, wenn es Problem auftritt (und das wird es...). Vielleicht funktioniert das auch mit zwei gleichzeitig gestarteten Delphi-Instanzen, eine für den Server, eine für den Client, hab ich nicht ausprobiert.

Ich hoffe, ich konnte dir damit ein wenig die Richtung zeigen. Die Informationen dazu habe ich durch reichlich ausprobieren und intensivem Stöbern im Supportforum zusammengetragen - ich weiß nicht, ob das wirklich der Königsweg ist, aber er funktioniert bei mir, und das auch mit großen Datenmengen: durch eine solche Verlagerung der Businesslogik auf den Server konnte ich die Berechnungszeit für einige Preisberechnungen von rund vier Minuten auf unter eine Minute reduzieren, allein dadurch, dass der Netzwerkoverload weggefallen ist.

Viele Grüße + viel Erfolg!

Udo

[Kostas]

Tausend Dank Udo für die sehr sehr ausführliche Beschreibung.
Ich werde es gleich mal umsetzen.
Ich hatte mir vorher schon das Beispiel /Old/Fetsch angeschaut.
Das geht in die gleiche Richtung. Was mich sehr irritiert hat ist,
dass die MemDataTables nur Clientseitig erstellt werden und nicht
mindestens zusätzlich Serverseitig. Eigentlich braucht er gar keine
anlegen. TDALocalDataAdapter das war der richtige Hinweis für die
Verknüpfung Serverseitig.

Ich habe zusätzlich AnyDAC lizenziert. RemObjects kann irgendwie mit
AnyDAC zusammenarbeiten. Eigentlich bin ich kein Freund von TDataTable
ich verwende lieber TQuery allerdings gibt es bei DA keine TQuery.
Kann ich irgendwie mit AnyDAC arbeiten oder lieber nicht. Möglicherweise
habt DA Funktionalität eingebaut die ich per AnyDAC nicht erreichen kann.

Gruß Kostas

[kretabiker]

Der AnyDAC-Treiber wird von DA unterstützt, muss jedoch von Hand in das Framework installiert werden - siehe http://wiki.remobjects.com/wiki/Inst...tabase_drivers. Klappt zumindest mit IBDAC problemlos.

DA stülpt sich quasi über den verwendeten DB-Treiber und bietet damit eine einheitliche, treiberunabhängige Schnittstelle mit "erweiterten Möglichkeiten". Ob du trotzdem direkt auf den DB-Treiber zugreifen kannst (unter Umgehung der üblichen DA-Vorgehensweisen), entzieht sich meiner Kenntnis. Selbst wenn - irgendwie wird damit der Sinn von DA ad absurdum geführt, finde ich. Was ist z.B. beim nächsten Treiberwechsel?

Zur Zeiten von IBX war ich auch kein Freund von TIBTable - das war ja auch ne ziemliche Krücke. Aber diese Komponente darf man glaube ich nicht wirklich mit den TDAMemDataTables vergleichen...