DataAbstract - eure Erfahrungen

[Garby]

Hallo,

über dieses Thema bin ich auf DataAbstract von RemObjects gestoßen.
Nun interessiert mich, welche Erfahrungen ihr damit gemacht habt.

z.B.:

• Welche Konfigurationen laufen bei euch?
• Hat schon jemand ein System, wo Client und Server (und DB) auf einem PC laufen? bzw.
• wo Client und Server ein Programm ist?
• Welche DB Systeme wurden von euch verwendet?
• Wie würdet ihr den Entwicklungsaufwand (gegenüber eines reinen C/S DB-Systems) einschätzen?
• Welche Strategien habt ihr für die Auslieferung (Installation Clients, Server, DB) ?
• Generell: auf was muss man aufpassen, bzw. geht irgendetwas überhaupt nicht oder gibt es vielleicht Bugs?
• Was fällt euch sonst noch dazu ein?

Danke für eure Antworten!

[dfried]

Na das sind ja ne Menge Fragen auf einmal
Also dann will ich mal...

Zitat von Garby:

Nun interessiert mich, welche Erfahrungen ihr damit gemacht habt.

Erst mal pauschal: sehr gute!!! Auch der Support über die Newsgroups bzw. im direkten Kontakt mit den Entwicklern ist sehr gut.

Zitat von Garby:

z.B.:

• Welche Konfigurationen laufen bei euch?

Was meisnt du mit "Konfigurationen"? Die Detailfragen stellst du unten doch schon
Nur so mal generell, wir haben bisher Projekte mit DA gemacht die sowohl innerhalb eines LANs als auch über WAN (ISDN / VPN) laufen bzw. auch Webserverfrontends mit DA-Serer als Backend.
Von der Performance zwischen WAN und LAN merkt man eigentlich fast keine Unterschiede, wenn man sich an ein paar "Regeln" hält (näheres siehe unten).

Zitat von Garby:

• Hat schon jemand ein System, wo Client und Server (und DB) auf einem PC laufen? bzw.

Jo, auf meinem Notebook läuft alles auf einer Kiste (zum entwickeln)

Zitat von Garby:

• wo Client und Server ein Programm ist?

Das leider noch nicht, wollte mir aber auch schon lange mal den "DLL-Server" ankucken

Zitat von Garby:

• Welche DB Systeme wurden von euch verwendet?

MySQL, MS SQL Server 2000 / 2005, ORACLE

Zitat von Garby:

• Wie würdet ihr den Entwicklungsaufwand (gegenüber eines reinen C/S DB-Systems) einschätzen?

Wenn man die Einarbeitung (Arbeitsweise von DA, welche Komponenten/Funktionalitäten gibt es, genereller Umgang mit dem Framework) abzieht, dann ist der Aufwand in etwa gleich.
Allerdings immer nur auf ein DB-System bezogen, wenn du mehrere DB-Systeme gleichzeitig unterstützen willst bist du mit DA eindeutig im Vorteil!

Zitat von Garby:

• Welche Strategien habt ihr für die Auslieferung (Installation Clients, Server, DB) ?

DB und Server werden einmal von uns installiert und dann bei Bedarf von einem Admin vor Ort "upgedated".
Die Clients werden über ein WebUpdate aktuell gehalten. Zusätzlich wird natürlich noch ein Prüfung gemacht, ob der Client auch zur aktuellen Serverversion passt.

Zitat von Garby:

• Generell: auf was muss man aufpassen, bzw. geht irgendetwas überhaupt nicht oder gibt es vielleicht Bugs?

Geht nicht gibts nicht
Wo man am Anfang ein wenig umdenken muss ist die "Arbeitsweise" von DA (bzw. allen Multi-Tier Applikationen im Vergleich zu C/S). Man muss sich
dran gewöhnen, dass die Verbindung generell quasi "zustandslos" ist. Ich hab also keine permanente Verbindung zur DB und mach alles in meiner "eigenen" DB-Session.
Das ist vor allem wichtig wenn es um Transaktionen geht, im Prinzip kann nur der Applikationsserver Verarbeitungen innerhalb "Transaktionen" machen.
Deshalb sollte die Hauptarbeit auch vom AppServer gemacht weden und nicht Clientseitig verarbeitet werden.
Wir machen das z.B. auch beim Drucken von Reports so, die werden komplett auf dem Server vorbereitet, an den Client geht dann nur noch das fertige (pepackte) PDF oder hald ein NDR für Rave, also minimaler Datentransfer.
Auch etwas anders ist z.B. das fetchen der Daten in einzelnen "Häppchen" von der Datenbank, das ist in einer C/S Umgebung kein Problem mit DA schon etwas aufwendiger.
Bezgl. Bugs: die Version 4 von DA für .Net ist ja noch recht neu, aber schon ziemlich stabil. Wir haben auch die Betaphase für DA4.Net mitgemacht und ich kann nur sagen, falls es irgendwo klemmt gibt normal schnell Abhilfe!

Zitat von Garby:

• Was fällt euch sonst noch dazu ein?

Man könnte noch viel zu DA sagen, aber das würde etwas ausufern, wenn du noch "spezielle" Fragen hast melde dich einfach.

[Garby]

@dfried: Danke für die ausführliche Antwort, das hilft schon mal sehr.

2 Sachen sind mir noch eingefallen:
1. Welche DBs werden "von Haus aus" unterstützt, bzw. wie aufwändig ist es einen Link zu entwickeln?
Oder funktioniert vielleicht jeder in .NET verfügbarer Provider?
2. Ist der Server im Normalfall nur ein vom Assistenten erstellter Datenlieferant, der die Anfragen des Clients durchreicht, oder wird vom Assistenten schon irgendeine Logik im Server implementiert? (evtl. Tansaktionssteuerung o.ä.)

Danke

[dfried]

Zitat von Garby:

@dfried: Danke für die ausführliche Antwort, das hilft schon mal sehr.

Keine Ursache

Zitat von Garby:

2 Sachen sind mir noch eingefallen:
1. Welche DBs werden "von Haus aus" unterstützt, bzw. wie aufwändig ist es einen Link zu entwickeln?
Oder funktioniert vielleicht jeder in .NET verfügbarer Provider?

Wie heisst es so schön auf deren Webseite:

Zitat:

Data Abstract for .NET and Mono is a data-access framework built on top of ADO.NET and designed to create distributed cross-database systems.

Also reicht also ein entsprechendenr Provider.
Bei DA für Delphi sieht das etwas anders aus.

Zitat von Garby:

2. Ist der Server im Normalfall nur ein vom Assistenten erstellter Datenlieferant, der die Anfragen des Clients durchreicht, oder wird vom Assistenten schon irgendeine Logik im Server implementiert? (evtl. Tansaktionssteuerung o.ä.)

Der Assistent generiert dir erst mal nur das Grundgerüst (Kommunikationskomponenten, ggf. Sessionmanagement usw.). Aber mit den Tools (Schemamanager, ServiceManager usw.) ist es dann weiterhin auch sehr einfach zusätzliche Abfragen, Commands, Services usw. dazu zu definieren. Im wesentlichen musst du dann immer nur den "Implementation"-Teil noch mit leben füllen, und da ist ja dann auch das Transaktionsmanagement möglich.
Es gibt da aber dann auch noch weitreichenden Funktionalitäten wie Businessprozessoren usw. mit denen du dann auch noch viel Arbeit erledigen kannst (z.B. bei allen Tabellen automatisch die Audit-Felder füllen usw.).

[sir-archimedes]

Hallo,

auch ich überlege momentan, ein System auf RO/DA aufzubauen. Ich dachte ursprünglich, dass RO/DA sehr ähnlich, wie die Enterprise Java Beans zum Beispiel funktionieren. Sehe ich es richtig, dass das so erst einmal nicht ist?

Ich würde nämlich eigentlich gerne für alle meine auftauchenden Objekte (z.B. Kunde, Rechnung, Rechnungsposition, etc.) eigene Klassen erstellen, auf die ich dann aber wie auf eine Datenbank-Tabelle zugreifen kann. Kann ich so etwas mit RO/DA machen und lässt sich ein System damit gut modellieren? Ich finde eine typische C/S-Anwendung mit Delphi lässt sich nämlich eher schlecht modellieren, da man keine wirklichen Klassen für die realen Objekte hat, sondern direkt mit DataSet u.Ä. arbeitet.

Schön fände ich es, wenn ich zum Beispiel einen Kunden so anlegen könnte:

Delphi-Quellcode:

Kunde := TKunde.Create;
Kunde.Name := 'Hans Müller'
Kunde.Adresse := TAdresse.Create;
Kunde.Adresse.Strasse := 'Wilhelmstr. 1';
...

Dann würde ich mir wünschen, dass automatisch ein solches Objekt in die Datenbank geschrieben würde und auf dem Applikations-Server überprüfungen durchgeführt werden, ob die Daten denn auch konsistent sind.

Geht das mit RO/DA?

Für mich ist es momentan nicht das wichtigste, verschiedene Datenbanksysteme zu unterstützen - das wäre ein nettes Feature, aber dafür würde ich mich nicht in eine neue Technik einarbeiten. Ich möchte gerne ein vollständig sauber gut durchgeplantes und damit leicht wartbares und erweiterbares System erstellen. Meint ihr, dass RO/DA dafür geeignet ist?

So ich hoffe mal, jemand liest bis hier hinten mit

Gruß,
Dominik