RemObjects Data Abstract, wozu Schema?

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

[Kostas]

Dann gibt es kein Zurück mehr.
Ursprünglich bin ich auf RO-DA gestoßen nachdem ich gelesen habe das RO-DA das Problem mit nicht stabilen, mobilen Anwendungen per UMTS und schlechter, komplett managed. Ich hoffe das ist wirklich so. Ist eigentlich über den gleichen Port den DA verwendet die Datasets zu den clients zu übertragen auch eine normale Kommunikation möglich?
Wenn also der Server einen bestimmten oder alle Clients eine Nachricht senden möchte.(Push service)
Oder muss dafür ein separater Port verwendet werden.(Firewall)

Gruß Kostas

[kretabiker]

Wir haben einen Kunden, der sitzt in Dahab/Ägypten am Roten Meer hinter einem ganz dünnen Draht mit bestenfalls Modemgeschwindigkeit, der gelegentlich auch noch abgezwackt wird - vermutlich, weil ein Esel drüber gestolpert ist. RODA fängt das ab und gibt ne passende Fehlermeldung aus bzw. macht ein Reconnect, ohne das der Anwender es sonderlich bemerkt und es überhaupt noch möglich ist - entsprechende Login-Prozeduren vorausgesetzt. Die Performance ist nicht berauschend, aber ausreichend (nur Preisdatenerfassung, nichts aufregendes).

Stichwort Push Service: Da fällt mir auf Anhieb "Event Sinks" zu ein - damit habe ich keine Erfahrungen, da mußt du mal nach dem Stichwort im RemObjects-Wiki gucken: http://wiki.remobjects.com/wiki/Even...rver_Callbacks.

Darin liegt auch schon eine Crux am Anfang: Welches Framework ist für was zuständig - ist die gesuchte Funktionalität bei RemObjects oder bei DataAbstracts zu finden? Man sucht schon ne Menge hin uns her, bis man das Prinzip verinnerlicht hat und weiß oder ahnt, wo was zu finden ist.

[Kostas]

Perfekt,

besten Dank und eine schöne Zeit.
Gruß Kostas