RemObjects und DataAbstract. Erfahrungen?

[alzaimar]

Ahoj!

Für unser nächstes Projekt (objektorientierte C/S-Anwendung, die MCMXXVI.te) sind wir auf der Suche nach einem entsprechenden Tool, das uns die Arbeit endlich mal erleichtern soll.

Reine objektorientierte Ansätze sind i.A. nicht sonderlich performant, also dachten wir an ein Mittelding:
Einzelne Objekte (Kunden, Produkte etc.) sollen als komplexes Objekt übertragen, Listen und Reports jedoch als simple (Client-)Datasets gezogen werden.

Als Sahnehäubchen sollen wir noch dafür sorgen, das die DB eventuell später auf Oracle rübergeschoben wird.

Es geht, um es nochmal zu sagen, um die Vereinfachung der Kette:

• DB --> Objekt auf Server --> Objekt im Client

sowie beim Abspeichern den umgekehrten Weg. Das ist eigentlich Alles. Wenn die Umgebung dann noch ähnliches wie die IAppServer-Schnittstelle bereitstellt, umso besser.

Ich dachte an RemObjects/Dataabstract oder auch InstantObjects auf Sourceforge.

Nun meine Frage:
Hat jemand Erfahrungen mit RemObjects & Co oder kann andere Tools empfehlen?

Jeder Kommentar ist willkommen. Ich ziehe mir heute mal die Demo und prüfe das sowieso.

Danke und eine schöne Woche noch!

[alzaimar]

Dezentes *push*

[choose]

Hallo alzaimar,

RO unterstüzt mit seinen Structs zwei etwas "ähnliches" wie Objekte, die Serialisiert werden können, ist dabei aber weit von einem O/R-Mapper entfernt. Weder Lazyfetching noch zirkuläre referenzen zwischen solchen Objekten können mit RO umgesetzt werden. Auch Methoden lassen sich nicht an Structs binden, sie entsprechen in diesem Punkten in etwa den Delphi-Records (ohne die Features seit D2006) und stellen einfache "Value-Objects" dar.
Eine Schnittstelle IAppServer ist unter diesen Einschränkungen einfach und elegant umsetzbar. Viele "Grundlagen" beim Entwickeln einer Three-Tier-Architektur sind bereits im Rahmenwerk vorgesehen und lassen sich gut den eigenen Vorstellungen anpassen.

DA ist auf die Verwaltung von Datasets zugeschnitten und bietet hier gleichfalls sehr mächte Unterstüzung. Gerade das Verarbeiten von Änderungen, die nicht unmittelbar in SQL übersetzt werden können, ist prima gelöst. Der Client kann davon entkoppelt eine Datenmenge vollkommen transparent verwenden.

Wir setzen die Kombination DA/RO weitestgehend ohne Structs ein. Reports und andere Listen-Werkzeuge (Grids) fahren in Delphi ohnehin besser mit Datasets, so dass wir dort keinen Einsatz für Objektkompositionen sehen. Ausführbare Logik ummantelt Datasets mit Objekten, ohne ihren Inhalt zu kopieren.

[alzaimar]

Hi choose,

Danke für die Informationen. Methoden würden sowieso nur im Rahmen von berechneten Feldern o.ä. umgesetzt werden, und wenn man das irgendwie im Client umsetzen kann, würde das reichen.

So wie es aussieht, werden wir uns wohl mit RO intensiver beschäftigen.

[dfried]

Hallo,

schau dir mal den Thread noch an. Der ist zwar für .net, aber da hab ich über usnere Erfahrungen mit RO/DA etwas berichtet und wir haben auch hauptsächlich mit der Delphi-Version gearbeitet.

[alzaimar]

Zitat:

Zitat von dfried

Hallo,

schau dir mal den Thread noch an. Der ist zwar für .net, aber da hab ich über usnere Erfahrungen mit RO/DA etwas berichtet und wir haben auch hauptsächlich mit der Delphi-Version gearbeitet.