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:

Delphi-Quellcode:

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...

[Kostas]

Hallo Udo,

nachdem ich ein Projekt mit dem Wizard erzeugt habe, existiert ein DataService_Impl.pas.
Auf der Form befinden sich je ein DataStreamer, EcmaScriptProvider und ein Schema.
Zunächst die Frage, wenn ich ein weiteren Service anlege mit dem Ancestor DataAbstractService
und definiere die Methoden (items) für meine spätere Implementierung, ist die Form erst einmal
leer. Also kein DataStreamer, EcmaScriptProvider und Schema. Sollen die drei
Komponenten von DataService_Impl.pas kopieren und somit je ein eigenes Schema anlegen werden oder
ist es üblich das Schema zentral zu verwalten. Mir persönlich würde ein eigenes Schema
pro Service besser gefallen, da es bei größeren Projekten besser partitioniert werden kann.

Allgemeines zum Schema bitte:
Ich habe eine Tabelle Adressen mit 78 Feldern. Angenommen, ich möchte Adressetiketten drucken.
Somit benötige ich nur die Adresse aus der Tabelle Adressen. Zum nächsten, möchte ich ein
Auftrag anlegen. Dafür benötige ich die Anschrift, Bankdaten und weitere Felder. Es sind also
zwei unterschiedliche Selects notwendig. Wie ist es gedacht, lege ich im Schema nur eine Tabelle
Adressen mit allen Feldern an, oder zwei Tabellen und gebe mein SQL-Statement selbst ein für die
unterschiedliche Untermenge der Felder?
Ich habe gemerkt, wenn ich mein eigenes Select eingeben, findet der Modeler die Metadaten nicht. Also Feldlänge, Typ, Entitäten u.s.w. Wenn ich jedoch die komplette Tabelle per AutoSQL ansreche habe ich die Metainfos mit in das Schema. Aktuell habe ich danach die überflüssigen Felder gelöscht nachdem ich von AutoSQL auf SQL umgestellt habe und die Metadata zu konsumieren.

Gruß Kostas

[kretabiker]

Du kannst die notwendigen Komponenten (DataStreamer, Schema) selbst auf dem Servicecontainer platzieren und dann die Properties entsprechend den vom Wizard erzeugten Komponenten setzen.

Ich verwende für jeden Service ein eigenes Schema, aus rein organisatorischen Gründen. Bei Datenbanken mit vielen Tabellen geht sonst im Schemamanager leicht die Übersicht verloren. Ich habe daher meine Services funktionsbereichsorientiert strukturiert.

Ob du für eine Tabelle mehrere DataTables im Schema anlegst, ist Geschmackssache. Es ist grundsätzlich möglich, mit einer DataTable zu arbeiten und dann per Dynamic Select die Spalten einzugrenzen - siehe Wiki. Lesenswert dazu sind auch die Ausführungen zur Klasse TableRequestInfoV5, ebenfalls im Wiki. Caveat: Ziemlich viel Tipperei. Und bei nicht-AutoSQL-Datatables werden trotzdem alle im Select-Statement enthalten Felder gefetcht und erst bei der Übermittlung zum Client die nicht angeforderten Felder entfernt - bei AutoSQL dagegen werden tatsächlich nur die angegebenen Felder beim Datenbankserver abgefragt.

Mit den Metadaten hatte ich auch bei eigenen Selects keine Probleme, ich muss nur manchmal auf Recreate bei den Feldern und Parametern des DataTables klicken. Im Client-MemDataTable muss ich die Tabellenstruktur nach jeder Änderung im Schema neu abfragen, da findet kein automatisches Sync statt. Bei den Feldern habe ich mir angewöhnt, die erzeugten Einträge zu prüfen, insbesondere bei Blobs mit SubType 1 für Text (in Firebird) kommt es hier gelegentlich zu Problemen. Und für Felder des Primary Keys, für die es in Firebird keine echten AutoIncs gibt, muss der Generator (falls verwendet) von Hand gesetzt werden.

[Kostas]

Hallo Udo,

bitte noch zwei Fragen:
Du schreibst, du hast mit dem Schema Modeler keine Probleme wenn du eine SQLs verwendest. Die Metadaten werden immer korrekt
erstellt. Ich verwende für mein Testprojekt eine Datenbank Firebird in der Version 1.5 Dialekt 1. Wenn ich über den Modeler
eine neue Tabelle anlege und verwende Statement Type = SQL und nicht AutoSQL werden keine Parameter erkannt und angelegt, auch nicht die Feld-Metadate wie FK, Required u.s.w. Wie gehst du vor? Du verwendest do auch Firebird oder?

Ich würde gerne mein Projekt Server und Client auf unterschiedlichen Maschinen testen. Wass muss ich bitte alles veröffentlichen und wie kann
ich den Connection String anpassen?


Gruß Kostas

[kretabiker]

Hallo Kosta,

in der Tat habe ich auch bei "eigenem" SQL wenig bis keine Probleme im Schema-Modeller: Wann immer ich da was eingebe oder ändere, werde ich beim Verlassen des SQL-Editors gefragt, ob Felder und/oder Parameter geändert werden sollen (was ich in der Regel mit ja beantworte). Die Probleme, wo ich von Hand nachregeln muss, hatte ich schon geschildert. Allerdings arbeite ich nicht - und das ist vielleicht der signifikante Unterschied - mit dem "neuen" Schemamodeller, der seit dem Autumn-2012-Release verwendet wird, sondern mit dem alten Modeller - weniger aus technischen Gründen, sondern aus Gewohnheit. Ob deine Probleme mit dem neuen Modeller zusammen hängen, weiß ich nicht. Ansonsten das Supportforum bemühen.

Zitat:

Zitat von Kostas (Beitrag 1193611)

Hallo Udo,
Ich würde gerne mein Projekt Server und Client auf unterschiedlichen Maschinen testen. Wass muss ich bitte alles veröffentlichen und wie kann
ich den Connection String anpassen?

Ich verwende für Entwicklung, Test und Produktion auch verschiedene Einstellungen. Dafür habe ich mir mal die Einstellungen aus dem Connection Manager des Server-Datamodules per rechten Mausklick auf Platte schreiben lassen und dann die darin aufgeführten Connections per Hand an die notwendigen Gegebenheiten des jeweiligen Servers angepaßt - ist trival, da ne XML-Datei. Beim Start des Server lese ich dann die jeweilige Datei(en) in den Connection Manager ein - fertig. Vom Client aus lasse ich noch beim Anmelden mit übergeben, welche Connection (als Connectionname) er denn verwenden möchte. Serverseitig prüfe ich dann beim Login, ob der Client die gewünschte Connection überhaupt verwenden darf - wenn nicht, gibt es ne Fehlermeldung, wenn ja, wird der Connectionname in der Session gespeichert, wie es die mitgelieferten Beispiele zeigen.

Viele Grüße

Udo

Ansonsten: Was meinst du mit veröffentlichen? Bei mir ist es nur die Server-Exe und die Dateien mit den Connections, die ich auf die jeweilige Server-Maschine schiebe. Wenn du den Server als Windows-Service laufen läßt, ist darauf zu achten, dass die Connection-Datei im Pfad liegt. Bei Remote-Servern noch den notwendigen Port freischalten, das ist eigentlich alles.