RemObjects Data Abstract, wozu Schema?

**Kostas**

Hallo Zusammen,

ich versuche RemObjects und Data Abstract zu verstehen.
Wenn ich das richtig verstanden habe, Wird durch das Schema in Data Abstract
die Datenbankstruktur "Nachgebildet" Jedes Element aus dem Schema muss mit
einem BusinessProcessor auf der Form verbunden werden. Eine MemDataTable kann
dann mit einem BusinessProcessor als Datenresource verbunden werden.

Das verstehe ich wenn unterschiedliche Datenbanken mit der gleichen Struktur
angesprochen werden sollen(Field Mapping).
Ich frage mich, ob das Schema auch notwendig ist wenn ausschließlich eine
Datenbank "Firebird" verwendet werden soll?

Was ich mir eigentlich vorstelle ist, im AppServer sollen anhand von SQLs die
auch Joinings enthalten können, Datasets produziert werden und die Clients sollen
die Datasets konsumieren können.

Geht dieser Weg so wie ich mir das vorstelle, oder muss ich zwingend mit Schema
und BusinessProcessor arbeiten?

Gruß Kostas

**Phoenix**

Das Schema ermöglicht es Dir, die den Clients zur Verfügung gestellten Daten anders zu Modellieren als sie physikalisch in der Datenbank liegen. Das ganze dient dazu, ein Business-Model mit Logik zu erstellen, ohne sich dabei auf die echte Tabellenstruktur festzufahren.

Du wirst merken, dass Du vorne auf einmal viel flexibler wirst, wenn Du die Datenbank nicht einfach so 1:1 an den Client durchreichst, sondern die technischen Details der Normalisierung hinter dem Schema versteckst. Deswegen ist das schon der korrekte Ansatz mit dem Schema zu arbeiten.

**Kostas**

Danke für die Antwort Sebastian,

ich spiele jetzt mal gedanklich eines meiner Projekte durch, welches relativ groß ist.
Es enthält 374 Tabellen. Die Adresstabelle hat 112 Felder. In der gesamten Anwendung
gibt es keine Stelle die alle Felder aus der Adresstabelle verwaltet. Wenn ich ein
Adressetikett drucke, hole ich mir nur die Adresse. Bei einem Auftrag hole ich mir
zusätzlich die Bankdaten für die Lastschrift. u.s.w. Alleine für die Adressen habe
ich mehrere Duzend TIB_Query(IBO Komponenten)die per Select mit Joins nur eine Untermenge
der Adressenfelder anfordern. Hier passiert auch punktuell die Datenprüfung.
(Die Prüfung punktuell ein klarer Nachteil gegenüber Multi-Tier)

Aber wie wird dieses Scenario konkret mit Data Abstract Schema abgebildet?
Habe ich ein Mapping auf die Tabelle Adressen mit 112 Felder und genau ein
BusinessProcessor, oder sind das mehrere Schemata-Table-Items mit jeweils einen
BusinessProcessor?

Gruß Kostas

**kretabiker**

Ich stelle gerade eines unserer Projekte von klassischem C/S auf RO/DA um - ca. 100 Tabellen, ca. 750 Tausend LOC - als Fingerübung, bevor es dann an die richtig großen Projekte geht.

Es gibt mehrere Möglichkeiten bei RO/DA:

- du kannst die Menge an zurückgelieferten Datensätzen über dynamisch generierte Where-Clauses bestimmen
- du kannst die Felder, die an den Client geliefert werden sollen, durch Verwendung Dynamic-Select bestimmen

In vielen Fällen reicht es (zumindest bei mir), die Tabelle als AutoSQL im Schema zu definieren - dann sind per Definition alle Felder drin - und dann im Client die Ergebnismenge mit DynamicWhere und/oder DynamicSelect den Wünschen anzupassen - die übertragene Datenmenge wird entsprechend den Statements bereits vom Server reduziert, nicht erst im Client (wie es z.B. bei einem Filter im Client-Dataset der Fall wäre).

Wird DynamicSelect verwendet, hat AutoSQL den Vorteil, dass der RODA-Server tatsächlich nur die angegebenen Felder bei der Datenbank abfragt. Mit selbstgestricktem SQL werden zunächt alle Felder, die im SQL-Statement angegeben sind, bei der DB abgefragt und erst im RODA-Server die nicht verlangten Felder ausgefiltert.

Damit hättest du im Idealfall eine Tabelle im Schema definiert und im Client ein TDAMemDataset, welches du mit verschiedenen dynamischen Statements fütterst. Ob das nun tatsächlich auch bei dir der Fall sein kann, weiß ich natürlich nicht.

Wenn dein Server in .NET geschrieben ist, kann auch DA SQL verwendet werden. Oder LINQ.

Details und Beispiele dazu finden sich im Wiki.

Ehrlicherweise muss ich sagen: Am Anfang treibt einem RO/DA schon mal in die pure Verzweiflung, wenn man so wie ich von der reinen C/S-Schiene kommt - die Lernkurve ist gerade am Anfang sehr hoch, die Doku nicht immer optimal, stellt nur einfache Fragestellungen dar oder ist nicht mehr auf dem neuesten Stand - man muss häufig ausprobieren, was geht. Aber es lohnt sich, durchzuhalten...

**Kostas**

Danke Leidensgenosse.

aktuell mache ich auch reine C/S Anwendungen mit IBO und Firebird.
RO-DA scheint ein mächtiges Werkzeug zu sein. Durch die intelligente Anpassung der SQLs die zum Server
gesendet werden, könnte vermutlich der Overhead bezüglich Performance keine Rolle mehr spielen.
Was bleibt ist der erhebliche Mehraufwand den eine Multi-Tier Umgebung mitbringt. Man muss schon
genauer abschätzen ob Multi-Tier für das konkrete Projekt Sinn macht. Doch leider ist es nicht immer
über die Glaskugel zu erfragen wie das Projekt sich in 10 Jahren entwickeln wird. Die Anforderungen des
Kunden wachsen oder auch nicht.

IBO soll ersetzt werden durch AnyDAC die ich schon gekauft habe.
Jetzt habe ich gesehen, wenn ich mich für RO-DA entscheide, dass es auch ohne AnyDAC gehen könnte.
Was RO-DA nicht haben wird, sind die Zusatzkomponenten z.B.: für Backup u.s.w.
Irgendwie habe ich bei den Beispielen den DataServer gesehen dass AnyDac direkt verwendet oder
unterstützt wird. So ganz habe ich das noch nicht herausgefunden wie es zusammenhängt.
Gruß Kostas

**kretabiker**

Was DB-Treiber angeht: RO/DA unterstützt von Haus aus eine Reihe Treiber, die ggfs. manuell installiert werden müssen - siehe

http://wiki.remobjects.com/wiki/Drivers. So auch in meinem Fall: Treiber ist IBDAC, wird von RO/DA unterstützt, manuelle Installation erforderlich - es ist dafür eine IBDAC-Lizenz erforderlich, damit die Installation möglich ist. Ähnlich sollte es auch bei AnyDac laufen.

**kretabiker**

Und was die Entscheidung für RO/DA angeht: Auch hier bei uns war die Entscheidungsfindung ein mühsamer, durchaus langwieriger Prozess, während dessen ich mich mit kleinen und kleinsten Projekten auf maximal Toolniveau mit der Materie RO/DA auseinandergesetzt habe - ich glaube, die erste RO/DA-Lizenz habe ich Sommer 2008 geordert, und ERST DIESES JAHR geht es ernsthaft an die Umstellung. Letztendlich ausschlaggebend waren die zusätzlichen Möglichkeiten, die ich dadurch erlange: Zum einen habe ich einen performanten, verschlüsselten, komprimierten Datenübertragungsweg, den ich von Delphi-, .Net- oder gar XCode-Clients nutzen kann. Zusätzlich besteht aber auch die Möglichkeit, mit skriptbasierten Sprachen wie z.B. PHP via Webservice/SOAP die gleiche Schnittstelle anzusprechen und damit browserbasierte Clients zu bedienen (ob es Sinn macht, tatsächlich die gleiche Schnittstelle zu nehmen oder parallel eine für SOAP aufzubauen, sei dahingestellt - wichtig ist: Es ist der gleiche Server!) - Stichwort Windows 8 und die neue WinRT-Welt oder mobile Clients.

Wohin die Reise letztendlich geht, kann ich nicht sagen. Aber die Möglichkeiten, die sich mir und meinem Delphi-Wissen mit RO/DA bieten, sind vielversprechend. Jetzt baue ich den Server mit Delphi. Sollte eines Tages die Entscheidung gefällt werden (müssen), nicht mehr auf Delphi zu setzen, kann ich in aller Ruhe den Server z.B. auf .NET umstellen und mir nen .NET-Spezi schnappen, der den/die Clients neu schreibt - oder nen HTML(5)-Spezi, der was für Browser macht. Oder beides. Oder alle drei Möglichkeiten parallel - was eben gerade benötigt wird: Die Businesslogik und die Datenbankhandlings liegen immer im RO/DA-Server, was mir unglaublich viel Flexibilität gibt bei den Clients - so richtig schlau müssen die im Gegensatz zu C/S-Clients ja nicht mehr sein...

Mal davon abgesehen: Die Freiheit beim Einsatz des verwendeten Datenbanksystems. Wir nutzen Firebird mit IBDAC und sind äußerst zufrieden. Was ist, wenn aber die erzeugten Datenmengen - es geht hier bei uns um touristische Daten, z.B. Hotelpreise, wo mal locker pro Hotel ein paar hunderttausend Datensätze auf einen Schlag in der DB erzeugt werden müssen - die Möglichkeiten von FB sprengen und den Einsatz von von mir aus Oracle verlangen? Den Clients bleibt es egal, durchs Schema sind sie von der Anpassung im Backend isoliert. Und das Schema anzupassen ist ja nun wirklich ein Kinderspiel im Vergleich zu den Änderungen bei einer reinen C/S-Anwendung - das habe ich schon zweimal durchexerziert (BDE/Paradox->IBX, IBX->IBDAC) und habe davon eigentlich die Nase gestrichen voll.

**PMM**

Auch wir benutzen RO-DataAbstract, mit FB,MSSQL/ORA via AnyDAC und das funktioniert auch sehr gut. Was man aber wissen sollte:
Man tauscht Programmieren gegen Konfigurieren. Das ist "in", hat aber so seine Tücken:
- Kommentare im Quelltext gibt es nicht mehr. Auch wenn RO sich bemüht hat, Ersatz zu schaffen: Da sieht man alles erst mit dem Schema-Editor...
- mal eben im Quelltext nachschauen wie das läuft geht also nicht mehr. Passiert ja alles knietief im RO/DA Baukasten...
- Stack-Trace bei Fehlern sind auch nicht mehr wirklich hilfreich...
Wie gesagt, das ist keine Kritik an RO/DA, aber zu beachten.
PMM

**Kostas**

Danke Udo für deine sehr ausführliches Statement.
Ich sehe schon, ich werde wohl auf RO-DA setzen. ist schon amüsant, bei mir war es (BDE/Paradox->IBX, IBX->IBO) und es sind immer noch Projekte die BDE, IBX und IBO kombiniert fahren. IBO umzustellen ist sehr schmerzhaft, da ich dessen Controls verwendet habe die nicht Dataset Kompatibel sind. Eine Umstellung auf AnyDAC bedeutet komplett neu schreiben.
@PMM
Auch dir schönen Dank für den Hinweis. Aktuell kann ich das noch nicht werten. Nur mal ein Beispiel: Ich habe eine Methode die ein Lieferschein in eine Rechnung für Sammellieferscheine kopiert. Ist keine offene Rechnung für Lieferscheine gerade vorhanden, wir diese neue Erzeugt und dann wird der Lieferschein hineinkopiert. Diese Methode ist ziemlich umfangreich wie man sich vorstellen kann. Diese Logik kann ich doch hoffentlich weiterhin wie gewohnt in Delphi machen. Nur dass diese Methode in der Mittelschicht- sprich RO-DA Server Modul steckt. Der Server veröffentlicht diese Methode mit den notwendigen Parameter. Der Client kann nur die Methode aufrufen. Ist das so?

Gruß Kostas

**kretabiker**

Zitat von Kostas:

Diese Logik kann ich doch hoffentlich weiterhin wie gewohnt in Delphi machen. Nur dass diese Methode in der Mittelschicht- sprich RO-DA Server Modul steckt. Der Server veröffentlicht diese Methode mit den notwendigen Parameter. Der Client kann nur die Methode aufrufen. Ist das so?

Ja, definitiv. Du kannst im Server quasi genauso programmieren wie im Client, also auch mit den TDAMemDataSets, wenn du Zugriff auf die Datenbanktabellen im SCHEMA brauchst (verbunden mit einem TDALocalDataAdapter). Was du nicht hast, wenn dein RO/DA-Server als Windows-Service läuft: ne GUI. Statusmeldungen, Fehlermeldungen sollten tunlichst nicht auf dem Server ausgegeben werden (können nicht angezeigt werden), sondern an den Client geliefert werden, als Rückgabewert oder so - das ist aber eine Einschränkung, die m. W. für alle Windows-Dienste gilt, nicht nur für RODA.