Ein TDataSet mit RemObjects übertragen

[Kostas]

Hallo Zusammen,

ich versuche gerade herauszufinden ob und wie ein DataSet von einem Server zu Client übertragen werden kann
mittels RemObjects. Vermutlich ist es so simpel dass er gar nicht extra erwähnt wird. Mich irritiert der RemObjectsServiceBuilder der als Rückgabewerte nur eine Handvoll Typen kennt. Ein DataSet wird nicht angeboten.
Kan wir jemand beschreiben wie ich ein DataSet übertragen kann?

Gruß Kostas

[Uwe Raabe]

Wenn ich mich nicht irre, ist diese Funktionalität Data Abstract vorbehalten.

[Kostas]

Zitat:

Zitat von Uwe Raabe (Beitrag 1191829)

Wenn ich mich nicht irre, ist diese Funktionalität Data Abstract vorbehalten.

Hallo Uwe,

das habe ich befürchtet.
Es ist so dass 100% meine Anwendungen mit Datenverwaltung zu tun haben. 90% davon sind reine Client/Server zwei Schichtenarchitektur. Der geringste Anteil erwartet eine Mehrschichtenarchitektur. Bis jetzt habe ich mich durch die Aufgabe drücken können bzw. per TCP lösen können. Wenn man sich jedoch mit einer Technologie näher beschäftigt, und sein Wissen auch produktiv einsetzten kann, so kommen immer mehr Anforderungen. Deshalb sehe ich die Mehrschichtenarchitektur als neue Herausforderung.
Mit DataSnap habe ich jetzt ein kleines Projekt umgesetzt. Es funktioniert hervorragend wenn der Kommunikationskanal stabil ist, also im LAN. Für die aktuelle Anwendung ist es leider nicht der Fall. Es ist eine mobile Anwendung über das UMTS und schlechter Netz.
Ich habe gelesen dass RemObjects genau das beherrschen soll. Deshalb beschäftige ich mich damit.
Für Mehrschichtenarchitektur Anwendungen fehlt mich auch noch das entsprechende Hinterundwissen welches sich unterscheidet zu Zweischichtenarchitektur. Ist dir Literatur darüber bekannt? Mich quellen Fragen wie:
-Müssen bei Mehrschichtenarchitektur primary und foreign keys GUID sein? (Ich hasse GUID, sie sind schlecht lesbar, können nicht chronologisch sortiert werden und werden von den DBMS Systemen deutlich langsamer angesprochen.
-Darf ich in der Datenbank keine Referenzielle Integrität mehr einsetzen? (Die Mittelschicht soll angeblich der Herrscher für die Geschäftslogik sein. RefInt. Hat mir schon mal den A.. gerettet weil ich übersehen habe das ein Datensatz bereits verwendet wurde und ich es löschen wollte.)
Und noch ein paar andere Sachen.

Gruß Kostas

[mjustin]

Zitat:

Zitat von Kostas (Beitrag 1191831)

-Müssen bei Mehrschichtenarchitektur primary und foreign keys GUID sein? (Ich hasse GUID, sie sind schlecht lesbar, können nicht chronologisch sortiert werden und werden von den DBMS Systemen deutlich langsamer angesprochen.

-Darf ich in der Datenbank keine Referenzielle Integrität mehr einsetzen? (Die Mittelschicht soll angeblich der Herrscher für die Geschäftslogik sein. RefInt. Hat mir schon mal den A.. gerettet weil ich übersehen habe das ein Datensatz bereits verwendet wurde und ich es löschen wollte.)

zu 1: nein, Multitier geht auch ohne GUID - IDs. (Sie haben aber auch Vorteile, wie zum Beispiel, dass sie praktisch keine Mengenbegrenzung haben, dass man Objekte über eine HashMap typunabhängig in einem Cache ablegen kann, und dass man sie clientseitig ohne Kollisionsgefahr erzeugen kann). Hinsichtlich Performance: ja, wenn man täglich Terabytes bewegt, können sie durchaus nachteilig sein :)

zu 2: doch, man 'muss' natürlich immer RI verwenden. Nur weil man einen Teil der Anwendung in eine andere Softwareschicht legt, heisst nicht das diese wie ein Staubsauger auch alle Logik aus der Datenspeicherungsschicht abziehen muss. Bei Triggern und Stored Procedures ergibt sich allerdings schon ein Migrationseffekt - vieles was man früher aus Performance- oder Sicherheitsgründen in der Datenbank ablegte, kann man in die mittlere Schicht verlagern. Damit ist eine dreischichtige Architektur of auch leichter änderbar als eine zweischichtige (Stichwort "Datenbankmetadatenänderung nur mit Unterschrift der GL").

[Kostas]

Hallo Michael,

danke für die Infos.
Bitte, wie werden bei Offline-Systeme Datensätze angelegt. Z.B.: Vertreter mit Laptop beim Kunden
legt ein Auftrag an. Wenn die Daten zu einem späteren Zeitpunkt in das Host-System eingespielt werden
sollen, dürfen die IDs nicht kollidieren. Eine Möglichkeit ist, zusammengesetzt PK zu verwenden wie
VertreterID(integer)+'.'+AuftragID(integer) Eine andere Alternative ist, beim einlesen die nächste
AuftragsID abfragen, im Offline-System den PK ersetzen durch CascadeUpdate keine Problem, und danach
einlesen. Nachteil dabei, wenn ein Auftrag ausgedruckt wurde, steht die falsche AuftragsID. Natürlich könnte
man diese wieder extra im Hostsystem verwalten u.s.w.
Zusammengesetzt PKs sind bei mir ein "no go" Allerdings habe ich ein Projekt damit erstellt und es funktioniert einwandfrei mit einem entsprechenden Importprogramm. Ist aber eine Menge Arbeit. Ic Ich habe auch schon gelesen das diversen ORMs dies selbst verwalten. Hat möglicherweise „Data Abstract“ hierfür etwas zu bieten?

Gruß Kostas