Umstieg von Delphi 6 auf ?

[Stephan Schneider]

Hallo,

wir haben eine über Jahre gewachsene Applikationswelt, entwickelt mit Delphi 6 unter Zugrundelegung der BDE. Die Applikationswelt besteht aus lauter modularen Packages, ist also in der Summe kein großer monolithischer Block.

Nun ist der Entschluss gereift, die BDE durch eine andere Middleware zu ersetzen. Aller Voraussicht nach wird es ADO werden. Darüber hinaus wäre es wünschenswert, aus der bestehenden Applikationswelt eine webbassierte Applikationswelt zu schaffen. Das heißt, an den Stellen, an denen eine Windows-Form die Benutzerschnittstelle zur Datenbank darstellt, soll künftig der Browser zum Einsatz kommen.

Und eine ganz wichtige Anforderung zu guter Letzt: Man möchte soviel wie möglich des Quellcodes wiederverwenden. Wenn es einfache, d.h. automatische Portierungen in andere Entwicklungsumgebungen geben sollte, dann käme dies auch in Betracht. Sich aber hinzusetzen und die ganze auf Delphi basierte Applikationswelt nach z.B. Java zu portieren, ist nicht gewünscht. Außer es gäbe - wie gesagt - einfache Möglichkeiten hierzu.

Was würdet Ihr raten? Welches Werkzeug? Welche Technologie für den Datenbankzugriff bzw. die Webbasierung? usw.

[Bernhard Geyer]

> Nun ist der Entschluss gereift, die BDE durch eine andere Middleware zu ersetzen. Aller Voraussicht nach wird es ADO werden.

Wenn Du nur MS SQL-Server oder Access einsetzt. Ansonsten ist ADO fehl am Platz. Hier ist eine Kaspelung der DB-Schnittstelle z.B. mit dem Bridge-Pattern angesagt. Und eine DB-Schnittstelle wie BDE oder ADO als Mittleware zu bezeichnen ist etwas zu viel des guten. Das leisten BDE und ADO nicht!

> Und eine ganz wichtige Anforderung zu guter Letzt: Man möchte soviel wie möglich des Quellcodes wiederverwenden.

Wenn Du sowohl die BDE entsorgen willst als auch eine Web-Ansatz verwenden ist die frage wie gut wirklich eine Kapslung der DB-Schnittstelle und der GUI erfolgt ist. Wenn du z.B. die DB-Schnittstelle über DB-Sensitive Controls in jedes Formular gezogen hast wird der portierbare Anteil (welche man ohne Änderung des Codes übernehmen könnte) vermutlich so ziemliche bei 0% liegen.

> Was würdet Ihr raten? Welches Werkzeug? Welche Technologie für den Datenbankzugriff bzw. die Webbasierung? usw.

Ohne weitere Infos zu den unterstützten Plattformen, Einsatzgebiete ist .NET mit ASP.NET, Java mit Java Server Faces oder PHP geeignet oder auch ein Win32-Einsatz mit Intraweb. Werkzeuge entsprechend des gewählten Frameworks

[Stephan Schneider]

Danke für Deine Antwort.

Die Applikation ist ziemlich gut modular aufgebaut. In einem Package befinden sich BDE-Datenzugriffskomponenten sowie die Datenquellenkomponenten. Auf den Forms selbst sind so gut wie keine Datenzugriffs-Controls (wenige Ausnahmefälle). Daher dürfte die Portierung - theoretisch zumindest - aufgrund der Kapselung gut von statten gehen dürfen.

Im Backend werden Oracle, MS SQL Server und ggf. weitere Systeme zum Einsatz kommen. Momentan steht auf Platz 1 der zu unterstützenden DBMS Oracle und MS SQL Server. Die restlichen Plätze sind Zukunftsmusik. Oder sollte man bereits hier eine Entscheidung z.B. für Oracle zu treffen und in nativer Weise darauf zugreifen?

Die Applikation wird auf Windows-Rechnern laufen, andere Plattformen sind nicht angedacht. Sollte Webbasierung Wirklichkeit werden sollen, dann stehen konkrete Webserver noch zur Diskussion. Theoretisch sollte der Webserver auch auf Unix-Plattformen (inkl. Derivaten) eingesetzt werden können.

Die Fragen, die sich jetzt stellen, sind grundlegender Art: Mit welchem Tool arbeiten wir weiter, welche Technologien setzen wir hierzu ein? Bauen wir weiterhin auf Borlandprodukte und deren Technologien oder verwenden wir gleich ein anderes Werkzeug (z.B. MS DevStudio, ASP.NET usw.). Wenn wir z.B. weiterhin auf Borland setzen, welche Entwicklungsumgebung bietet sich da an? Welche Technologie zur Webbasierung? Umsteigen auf .NET oder nicht? Oder doch schon gänzlich in die Javawelt einzutauchen oder auf Borland bzw. Microsoftprodukte in der Entwicklung zu setzen.

Ich muss eingestehen, nach Delphi 6 nicht mehr mit Borland Produkten gearbeitet zu haben. Eigentlich habe ich mich aus der Entwicklung nahezu gänzlich zurückgezogen. Für mich geht es jetzt darum, einen Überblick zu bekommen, welche Technologien mit welchen Werkzeugen sinnvoll sind.

Noch ein Nachtrag, um die Situation besser einschätzen zu können.

Die gegenwärtige, BDE-basierte Applikation läuft nicht ganz so gut mit Oracle zusammen. Genau genommen mit den neueren RDBMS gar nicht mehr. Dies ist auch der Hauptgrund, warum man nun eine Applikation braucht, die mit Oracle und MS SQL Server läuft.

Der einfachste, da ceteris-paribus, Weg, ist die alte BDE zu entsorgen und durch ADO zu ersetzen. ADO garaniert die Zusammenarbeit mit Oracle und MS SQL Server. Hieße im Klartext, BDE-Komponenten raus, ADO-Komponenten rein. So die simple, theoretische Philosophie. Nur, ob man dadurch den richtigen Weg in die Zukunft beschreitet, bleibt unklar. Daher stellt man sich jetzt die obigen Fragen: Werfen wir nur die Zugriffsschicht raus und ersetzen sie durch eine andere (momentan fällt mir eben nur ADO als BDE-Ersatz ein)? Oder aber nutzen wir die Gunst der Stunde und überlegen uns, was für weitere Aktionen eventuell sinnvoll wären.

[Stephan Schneider]

Entschuldige, noch ein kleiner Nachtrag, um die Situation besser einschätzen zu können.

Die gegenwärtige, BDE-basierte Applikation läuft nicht ganz so gut mit Oracle zusammen. Genau genommen mit den neueren RDBMS gar nicht mehr. Dies ist auch der Hauptgrund, warum man nun eine Applikation braucht, die mit Oracle und MS SQL Server läuft.

Der einfachste, da ceteris-paribus, Weg, ist die alte BDE zu entsorgen und durch ADO zu ersetzen. ADO garaniert die Zusammenarbeit mit Oracle und MS SQL Server. Hieße im Klartext, BDE-Komponenten raus, ADO-Komponenten rein. So die simple, theoretische Philosophie. Nur, ob man dadurch den richtigen Weg in die Zukunft beschreitet, bleibt unklar. Daher stellt man sich jetzt die obigen Fragen: Werfen wir nur die Zugriffsschicht raus und ersetzen sie durch eine andere (momentan fällt mir eben nur ADO als BDE-Ersatz ein)? Oder aber nutzen wir die Gunst der Stunde und überlegen uns, was für weitere Aktionen eventuell sinnvoll wären

[Bernhard Geyer]

> Die Applikation ist ziemlich gut modular aufgebaut. In einem Package befinden sich BDE-Datenzugriffskomponenten sowie die Datenquellenkomponenten. Auf den Forms selbst sind so gut wie keine Datenzugriffs-Controls (wenige Ausnahmefälle). Daher dürfte die Portierung - theoretisch zumindest - aufgrund der Kapselung gut von statten gehen dürfen.

Dann sollte als erstes diese Kapslung vervollständigt werden

> Im Backend .... Oder sollte man bereits hier eine Entscheidung z.B. für Oracle zu treffen und in nativer Weise darauf zugreifen?

Man sollte sich nicht auf ein DBMS festnageln lassen. Der nächste Kunde will gleich das nächste DBMS. Nur ein DBMS zu unterstützen heißt auch ins Ventor Lock-In Antipattern zu fallen.

> Sollte Webbasierung Wirklichkeit werden sollen, dann stehen konkrete Webserver noch zur Diskussion. Theoretisch sollte der Webserver auch auf Unix-Plattformen (inkl. Derivaten) eingesetzt werden können.

Dann bleibt eigentlich nur Java übrig für die Web-Implementierung.

> Die Fragen, die sich jetzt stellen, sind grundlegender Art: Mit welchem Tool arbeiten wir weiter, welche Technologien setzen wir hierzu ein? Bauen wir weiterhin auf Borlandprodukte und deren Technologien oder verwenden wir gleich ein anderes Werkzeug (z.B. MS DevStudio, ASP.NET usw.). ...

Ich denke diese Entscheidung müßt ihr intern gründlich überlegen.

- Java mit wirklicher Plattformunabhänigkeit
- .NET mit sehr guter Performance und produktivität unter Windows.
- "Alte" Win32-Anwendung erstmal weiterentwickeln da auf Client weder Java noch (aktuell jedenfalls) .NET ein Killerargument ist. Und nur mehrer Mannjahre zu investieren um das gleiche anzubieten wie jetzt ...

> Ich muss eingestehen, nach Delphi 6 nicht mehr mit Borland Produkten gearbeitet zu haben. Eigentlich habe ich mich aus der Entwicklung nahezu gänzlich zurückgezogen.

Borland durchlebt mal wieder ein Lernphase wie zu Inprise-Zeiten mit dem Problem das 2 Versionen (8+2005) von Delphi nicht zu gebrauchen waren.

> Die gegenwärtige, BDE-basierte Applikation läuft nicht ganz so gut mit Oracle zusammen. Genau genommen mit den neueren RDBMS gar nicht mehr. Dies ist auch der Hauptgrund, warum man nun eine Applikation braucht, die mit Oracle und MS SQL Server läuft.

Kein Problem. Bridge-Pattern und z.B. die Oracle-Komponenten von Core Labs. Kosted < als 500 € und einige Tage umbauarbeiten.

> ADO garaniert die Zusammenarbeit mit Oracle und MS SQL Server.

Wo steht das man das gut kann. Ich höre eigentlich sehr oft von Problemen mit Oracle + ADO (vor allem den der MS-Provider verwendet wird)

> Hieße im Klartext, BDE-Komponenten raus, ADO-Komponenten rein. So die simple, theoretische Philosophie.

Die Probleme (und Zeitaufwand) steckt im Detail. Also erst Bridge-Pattern für Kapslung

> Nur, ob man dadurch den richtigen Weg in die Zukunft beschreitet, bleibt unklar.

ADO ist eh schon wieder veraltet (jedenfalls für MS), da für MS eh alles .NET sein wird

[Stephan Schneider]

Könntest Du mir ein paar gute Quellen zum Bridge-Pattern nennen? Eventuell mit Beispielcode?

Ich weiß, Google hilft, so manches Problem zu lösen, aber bevor ich jetzt in Form des Suchens das sprichwörtliche Rad neu erfinde, wäre es gut, wenn Du ein paar Quellen zum Bridge-Pattern bereits parat hättest.

Laut Deinen Ausführungen scheint im Bridge-Pattern der Schlüssel zum Erfolg im Hinblick auf die Datenbankanbindung zu liegen. Beim Rest: Java für echte Plattformunabhängigkeit, MS-Welt mit .NET. IntraWeb hatte ich auch mal bereits vor Jahren gehört. Ist das eine echte Alternative zu den genannten webbasierten Technologien (JSF, ASP.NET)

[Bernhard Geyer]

> Ich weiß, Google hilft, so manches Problem zu lösen, aber bevor ich jetzt in Form des Suchens das sprichwörtliche Rad neu erfinde, wäre es gut, wenn Du ein paar Quellen zum Bridge-Pattern bereits parat hättest.

Quellcode ist schlecht da ich in der Firma damit arbeite :-)
Schau dir doch mal die Erklärung in <a href="http://de.wikipedia.org/wiki/Bridge_%28Entwurfsmuster%29">Wiki</a> an.

>Laut Deinen Ausführungen scheint im Bridge-Pattern der Schlüssel zum Erfolg im Hinblick auf die Datenbankanbindung zu liegen.

Das Brückenmuster ist mit sicherheit eine Möglichkeit. Es gibt auch andere ähnliche Ansätze.

> Beim Rest: Java für echte Plattformunabhängigkeit, MS-Welt mit .NET. IntraWeb hatte ich auch mal bereits vor Jahren gehört. Ist das eine echte Alternative zu den genannten webbasierten Technologien (JSF, ASP.NET)?

Im Gewissen Rahmen: Ja. Kommt darauf an was man machen will. Da es ja kein Kylix mehr gibt es man aber damit auf Windows-Server angewiesen. Auf der EKON war ich auch in einem Vortrag der gezeigt hat wie man IntraWeb und den AJAX-Ansatz relativ einfach kombiniert

[Stephan Schneider]

Okay, dann versuche ich das ganze mal aus meiner Sicht zu schildern. Im Prinzip würde ich bei einem Bridge-Pattern folgendes machen!?

abstrakte Klasse: TView
Beschreibung: Bietet eine Ansicht auf Daten (z.B. in einem Grid)

abstrakte Klasse: TDatabase
Beschreibung: Kapselt den DB-Zugriff
Methode(n): LoadTable(const TableName: String; View: TView); virtual;

implementierende Klasse TDatabaseOracle
Methode(n): LoadTable(const TableName: String; View: TView); overwrite;

implementierende Klasse TDatabaseMSSQL
Methode(n): LoadTable(const TableName: String; View: TView); overwrite;

Wird Oracle verwendet, arbeitet z.B. eine Unit mit einer erzeugten Instanz von TDatabaseOracle. Ähnliches für MS SQL Server. Aufgrund der hierarchischen Abwärtskompatibilität bei Klassen kann man mit einer Instanz der abstrakten Klasse TDatabase arbeiten. Die "echte" Instanz stammt dann konkret von einer implementierenden Klasse.

Fazit: Das Muster ist sehr gut geeignet, um den DB-Zugriff zu kapseln und per se keine Einschränkung hinzunehmen. Die Applikation müsste aber auf dieses Pattern getrimmt werden, was einen nicht zu unterschätzenden Umstellungsaufwand mit sich bringen dürfte

[Bernhard Geyer]

Es fehlt noch die TBaseDB-Klasse welche die unterscheidung der zu verwendenden (z.B. über Property oder ähnlichen) TDatabase-Nachfolge-Klasse fällt. Ein Nachfolger von TDatabase ist dabei eine Member in dieser Klasse und diese Klasse leitet viele Aufrufe 1:1 durch.

> ... unterschätzenden Umstellungsaufwand mit sich bringen dürfte.

Stimmt. Aber wenn man ihn einmal gemacht hat überwiegen die Vorteile

[Stephan Schneider]

Dass ADO (nicht .ADO.NET) auch Risiken in sich birgt, ist mir mittlerweile klar. Somit dürfte ADO auch nicht mehr infrage kommen und aus dem Rennen sein.

Bleiben Java bzw. .NET!

Nehmen wir mal, wir entscheiden uns für .NET. Welche Entwicklungsumgebung würdest Du dann nehmen? Borland hat sich mit einigen Delphi-Versionen nicht gerade mit Ruhm bekleckert. Daher wäre eine Entscheidung zugunsten einer Delphi-Umgebung genauestens zu hinterfragen. Könntest Du das neue Delphi 2006 empfehlen? Oder doch lieber mit MS Visual Studio 2005 arbeiten

[Bernhard Geyer]

Ganz klar ist aktuell für .NET das VS.NET 2005 zu empfehlen. Die aktuellen Delphi-Versionen hinken hinterher. Evtl. wäre auch ein Blick auf SharpDevelop zu empfehlen

[Stephan Schneider]

Ich möchte Dir an dieser Stelle mal ein riesengroßes Dankeschön aussprechen für Deine Diskussion mit mir zu den diversen Themen :-)

Liege ich mit meiner Einschätzung bzgl. ADO richtig? Nicht auf ADO zu setzen, sondern - wenn überhaupt - auf ADO.NET

[Bernhard Geyer]

> Liege ich mit meiner Einschätzung bzgl. ADO richtig? Nicht auf ADO zu setzen, sondern - wenn überhaupt - auf ADO.NET.

Nein, nicht ganz. Wenn Du die Entscheidung treffen solltest mit/für .NET zu entwickeln das ist ADO.NET die Wahl (auch wenn man evtl. dann noch entscheiden sollte evtl. sowas wie N/Hypernate oder ECO (ok, wäre wieder Borland) einzusetzen. Für Win32 ist ADO für Access und den MS SQL-Server die erste Wahl. Werdet ihr nach Java gehen das ist JDBC die Qual der Wahl

[Stephan Schneider]

Bliebe noch die Frage nach Oracle...

Bitte bewerte (kritisch) die folgenden Szenerien:

Szenerie 1:
Ich werfe die BDE-Zugriffskomponenten raus und ersetze sie durch ADO-Komponenten. Das Ganze läuft weiterhin unter Delphi 6 ab, die letzte lizenzierte Version. Damit ist der Migrationsaufwand de facto am geringsten, da so gut wie alles gleich geblieben ist. Wird im Backend MS SQL eingesetzt, ist ADO - laut Deiner Aussage - ohnehin erste Wahl. Aber was ist mit Oracle? Da die nun zu realisierende Lösung mindestens drei bis vier Jahre halten soll, könnte ich doch mit ADO in die gleiche Falle tappen wie seinerzeit mit der BDE. Irgendwann gibt es ein Oracle-Release, für das kein passender Treiber für ADO existiert und es macht boom. Vor dem Hintergrund einer einfachen Migrationsstrategie und Oracle als Backend scheidet doch diese Szenerie so gut wie aus, oder?

Szenerie 2:
Wenn ich die Anwendung wirklich Datenbankunabhängig gestalten will, so ist der konzeptionelle Einsatz des Bridge-Pattern angebracht. Nehme ich aber derartige Umbaumaßnahmen in Kauf, dann kann ich gleich z.B. serverseitige Verarbeitungsprozesse realisieren und diese mit was auch immer kapseln (ADO->MS SQL, ODAC->Oracle), da ich ohnehin für jedes DB-System den Zugriff explizit realisiere.

Aufgrund der Tatsache, dass ADO "alt" einzustufen und der Support im Hinblick auf Oracle mit großen Fragezeichen zu versehen ist, bleibt - unter rein logischen Vernunftsgründen - eigentlich nur Szenerie 2 übrig (lassen wir mal Java außen vor)

[Bernhard Geyer]

zu 1:
Da ich bei Oracle native Komponenten verwende weiß ich nicht wie gut Oracle seine ADO-Treiber pflegt bzw. wie Hoch-Prio das von Oracle angesetzt ist. Ich glaube aber nicht das hier Oracle mehr viel Energie verwendet. Der MS Provider für Oracle kann man eh komplett vergessen. Da geht fast gar nichts.

zu 2:
Es ist Aufwand, den man aber gegenrechnen sollte zu:
- BDE weiter schlecht und recht unterstützen
- Portierung nach .NET/Java mit mehreren Mannjahren Arbeit um den gleichen Stand zu erreichen.

Ich sehe für "normale" Desktopanwendungen noch nicht den großen Druck zu portieren an. Selbst haben wir auch eine 2-Gleisiges System. Delphi für Win32 und Java für Server und Web. Einzig allein Avalon könnte den Druck auf Desktopanwendungen erhöhen aber es ist fraglich da die grafischen Vorteile bei den kleinen Vista-Versionen abgeschalten sind