Hallo zusammen,

wir haben einen funktionierenden Delphi-Dinosaurier im Einsatz. DB ist MS-SQL.
Jetzt sagt Cheffe, eine proprietäre Client-Server Anwendung ist nicht mehr zeitgemäß und damit braucht man sich an keiner Ausschreibung mehr beteiligen.
Man braucht entweder OpenSource oder wenigstens offene Schnittstellen, und das gehe mit einem AppServer am besten. Außerdem können so die Funktionen ("ändere Zeile X in Tabelle Y") auch besser von nicht-Delphi Frontends genutzt werden.

Wir setzen also schrittweise einen Appserver zwischen die Dephi.exe und die Datenbank.
Dazu nehmen wir eine eigene (letztlich u.a. von TFDMemtable) abgeleitete Dataset-Klasse, die den .adapter (und einiges andere auch) wegläßt und stattdessen via TREST*-Klassen mit dem Appserver kommuniziert.

Es scheint mir alles ein bischen von hinten durch die Brust ins Auge zu sein und ich frage mich, ob es auch anders geht.

Wenn die Vorgabe ist, die Applikation soll nicht selber direkt auf die DB zugreifen, ist dann Delphi überhaupt noch eine vernünftige Option als Entwicklungsumgebung?
Und falls ja, gibt es einen eleganteren Ansatz dazu als den kurz eben angerissenen?

Zum Verständnis: Der Dinosaurier ist eine Anwendung die sich in einem einzigen Prozess auf dem Client-Rechner um Darstellung, Logik und Kommunikation mit der Datenbank kümmert?

Hallo,
warum sollte Delphi dafür nicht funktionieren?

https://www.embarcadero.com/de/produ...es/middle-tier

Der Vorteil der Zwischenschicht ist die zentralisierung der Business Logik vor allem wenn mehrere verschiedene Arten von Clients auf den Server zugreifen.
Zum zweiten kann der Server Prozess in kleinere Teile zerlegt werden und man hat eine bessere Skalierbarkeit.
Es gibt schon einige Gründe die dafür sprechen und Delphi unterstützt das ja auch in den aktuellen Version sehr gut wie ich finde.
Wir migrieren unsere Anwendung auch aktuell in diese Richtung.

Danke für die schnellen Antworten.

Zitat von Der schöne Günther:

Zum Verständnis: Der Dinosaurier ist eine Anwendung die sich in einem einzigen Prozess auf dem Client-Rechner um Darstellung, Logik und Kommunikation mit der Datenbank kümmert?

Ja

Zitat von hoika:

Hallo,
warum sollte Delphi dafür nicht funktionieren?
https://www.embarcadero.com/de/produ...es/middle-tier

Verstehe ich das richtig, das der AppServer dabei mit Delphi (Datasnap) umgesetzt wird?
Die strategische Entscheidung bei uns ist aber die, das der Appserver in einer anderen Technologie umgesetzt wird (kann der Kollege besser programmieren). Und das die Delphi.exe auch nur über den Appserver mit der DB spricht. Also in der Grafik auf der von dir verlinkten Seite würde die direkte Verbindung "FM Client <-> Firedac" wegfallen. Macht dann Delphi noch Sinn?

Zitat von jsheyer:

...Delphi unterstützt das ja auch in den aktuellen Version sehr gut wie ich finde. Wir migrieren unsere Anwendung auch aktuell in diese Richtung.

Was meinst du damit konkret? Das gleiche, was @Hoika soeben geschrieben hat, oder habt ihr noch einen anderen Ansatz?

Zitat von jsheyer:

...Delphi unterstützt das ja auch in den aktuellen Version sehr gut wie ich finde. Wir migrieren unsere Anwendung auch aktuell in diese Richtung.

Was meinst du damit konkret? Das gleiche, was @Hoika soeben geschrieben hat, oder habt ihr noch einen anderen Ansatz?[/QUOTE]

Wir entwickeln Libaries für den ApacheServer der dann als REST Server fungiert und die Anfragen entsprechend verarbeitet. Damit kann jeder Client, also auch Fremdentwicklungen umgehen.