![]() |
Modernisierung von Legacy-Anwendungen
Gibt es hier noch jemanden, dem eine Modernisierung einer Legacy-App ins Haus steht?
- Datenbank Single User/Multi User - Multi Platform (jedenfalls Windows/Mac) - Teilbereiche Mobile Ich würde mich gern zu den Themen austauschen, vielleicht können wir einander da ja unterstützen + von unterschiedlichen Blickwinkeln profitieren? Hat jemand Interesse? |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Mobile - da gibt es schon Legacy? :shock:
Ansonsten habe ich es jeden Tag mit Legacy-Anwendungen zu tun. Sie sind 15-30 Jahre alt. Empfehle dazu auch ![]() |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Scheint mir plausibel. Der Istzustand wäre auch interssant.
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Also ja. Auch beim Mobil dürfte sich sehr viel getan haben (und nicht nur auf HW-Ebene mit den Erstgeräte auf Windows CE-Basis). |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
In den allermeisten Fällen geht das in die Richtung von Ver-Service-fizierung von Businesslogik und Datenzugriff, so daß ein weiterer On-Premise Betrieb möglich ist, sich das ganze Gebilde aber in aller Regel deutlich besser in Richtung Cloud bewegt sowie von Plattformübergreifenden und teilweise auch Offlinefähigen Client-Anwendungen. Die Ver-Service-fizierung ist dabei allerdings in aller Regel der Knackpunkt, denn sobald die Kunden sinnvolle APIs anbieten können, tun sich auf einmal neue Welten an Integrationsszenarien und damit auch neuen Geschäftsmöglichkeiten auf. Allerdings ist bei uns der Technologiestack ein anderer als Delphi. |
AW: Modernisierung von Legacy-Anwendungen
Wir haben vorletztes Jahr unsere Software von Delphi 7 auf Delphi 10.3 geupdatet. Das war zwar ein ganz schöner Krampf, aber inzwischen läuft es einigermaßen rund. Wenn ihr das wirklich vor habt, stellt euch auf viel Ärger ein (zumindest wenn ihr ein so altes Projekt updatet). Mir fliegen immer noch 100te Deprecated-Meldungen beim Compilieren um die Ohren, weil wir einfach nicht dazu kommen alle Programmteile so zu updaten, dass aktuelle Componenten dafür genutzt werden. Einige Komponenten mussten wir sogar komplett ersetzen, da sie unter Delphi 10.3 nicht mehr lauffähig waren. Also nehmt euch gut Zeit wenn ihr ein so altes Projekt updaten wollt. Das wird dauern. Wir haben gut 3 Monate dafür gebraucht, bis alles wieder lief.
|
AW: Modernisierung von Legacy-Anwendungen
Die Software läuft gut + wird aktiv vertrieben. Ich würde gern ca 2/3 binnen Jahresfrist erneuert haben, das lässt sich gut abgrenzen. Weil da stellenweise noch Code aus dem letzten Jahrtausend :- ) drin ist, würde ich alles, was allgemeiner Basiscode ist kübeln + neu machen. Ich würde auch alles, was mit Ausgabe etc zu tun hat, kübeln. Da gibt es viel zu viel neues und besseres (bzw gibt es manches jetzt eben auch nicht mehr). Ich würde wirklich nur den Kern der Businesslogik mitnehmen. Viele Anforderungen haben sich geändert und vieles weiß ich mittlerweile besser, bzw würde ich anders machen, weil ich weiß, wo in der Praxis Probleme auftauchen.
Aber vorher sind halt ein paar Grundsatzentscheidungen zu treffen: - Als Web-Anwendung umsetzen? Native Anwendungen je Plattform? Saas? - Welche Datenbank bei Stand-Alone bzw bei MultiUser - Deployment und Installer bei Multiplatform - Reporting und Ausgabe - Import/Export/Replikation/Cloud - Aktualisierung großer Datenmengen beim Kunden draußen Und ja. Die Punkte waren als Ziele gedacht. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Damit bemerkst du nicht mehr wenn neue Meldungen rein kommen da ob nun 400 oder 410 Meldungen kommen keinen Mehr interessiern. Zitat:
Und nach Umstellung dann nicht mehr nötige Kompos (z.B. bsala webbrowser-Komponenten) dann auch entsorgt. Zitat:
D6 -> XE6 -> 10.2 - 10.4 war der Weg und möchte nie mehr zu D6 zurück |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Im Falle von OpenSource geht schon seit Jahren sehr vieles in Richtung PostgreSQL. Oberfläche: Wir machen Grundsätzlich nur Web-basierte Anwendungen. Läuft wirklich problemlos überall: Link öffnen und App benutzen. That's it. In einigen Fällen installierbar als PWA (Progressive Web App), in den allerwenigsten Fällen und nur wenn es wirklich sein muss gewrapped in sowas wie Corodova. Der Grund ist dass man mit einer einheitlichen Code-base wirklich alle Plattformen und vor allem auch alle Form-Faktoren (kleine hochkant Screens auf Smartphones über Tablet-Layouts bis hin zu Ultra-Wide Screens am Desktop) bedienen kann. Schaut man sich z.B. Spotify an, Slack, MS Teams, Discord, Google Office, O365, Whatsapp, an (und viele viele andere Anwendungen), merkt man in den meisten Fällen noch nichtmal das das hintendran eigentlich alles nur Webseiten sind. Selbst 3D-Animationen mit 60FPS bekommt man damit problemlos hin. Und wenn man ehrlich ist: Bei Geschäftsanwendungen ist es in aller Regel auch vollkommen egal wenn es Web-ig aussieht, hauptsache der Benutzer hat überall ein einheitliches Look & Feel und findet sich schnell zurecht. Bei Consumer-Anwendungen sieht das allerdings ggf. anders aus, hier mag es unter Umständen sinnvoll sein, das man für eine möglichst breite Akzeptanz Plattform-Nativ aussehen will. PWA's kann man bei Android auch einfach von der Webseite aus installieren. Will man das auf iOS in den Appstore bringen bleibt leider nichts anderes über als es zu Wrappen (z.B. Cordova), aber auch das ist in aller Regel kein Problem. Die logische Schlussfolgerung daraus ist: Wenn man das Backend für das Web-Frontend sinnvoll ver-API-fiziert, ist es ein superkleiner Schritt das als SaaS bereitzustellen. Sync-Thematiken mit lokalen Installationen sind meistens nur ein kleines technisches Detail (das haben wir auch schon etliche male gebaut). |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Im Backend setzen wir auf .NET (Core) 5+, was seit der .NET Core-Reinkarnation deutlich schlanker, moderner und performanter unterwegs ist. |
AW: Modernisierung von Legacy-Anwendungen
Ja, Angular soll recht cool sein. Aber da hab ich kein projekttaugliches Know-How.
Am liebsten wär mir, wenn sich 2,3 finden, die vor derselben Hürde stehen wie ich. Dann einigt man sich auf einen technischen Unterbau, einer macht das reporting, einer das Benutzermanagement etc. Die Core-Logik macht wieder jeder selber + nutzt die Bausteine der anderen. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Angular ist hier fast schon wieder "Schnee von Gestern" und die neuen Frameworks sind Vue und React (und noch ein 2-3 andere). Welche in 5 Jahren noch aktiv gepflegt wird oder "untergeht" ist offen. Wir haben auch mal auf ein Framework von google gesetzt, welches aber mittlerweile als aussterbendes Framework gilt. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Ja das ist eine schwere Entscheidung mit den JavaScript/CSS Frameworks. Wir haben mittlerweile 3 WebApps mit verschiedenen Bootstrap Varianten am Start, der Rest ist halt Javascript/Typescript. Aber schon das ist nervig.
Ich fand die Aussage von Herrn Suer (deutscher Entwickler/SymCom glaube ich) beim TMS WebCore Seminar vorgestern bei TMS interessant: Sie setzen WebCore (also Pascal --> Javascript Transpiler mit entsprechender Pascal RTL) ein um nicht bei einem falschen Javascript Framework zu landen. Werde da jetzt auch mal intensiver reinschauen, lizensiert haben wir es schon länger aber nur kleinere Sachen probiert. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Und es gibt tatsächlich relativ einfache, fachliche Gründe die einem bei der Entscheidung helfen, wann man welches Framework nehmen sollte. React kommt von Facebook, und ist primär für Anwendungen gedacht, die viel anzeigen und viele, aber dafür immer die gleichen Eingabemöglichkeiten haben. Also eine Ellenlange Timeline von Posts und unter jedem das immer gleiche Kommentar-Eingabefeld und Reaktionsmöglichkeiten (daher der Name: React), auf die Posts. Baust Du also das neue Facebook: React it is. React ist ausserdem mehr eine Sammlung von Bibliotheken als wirklich ein Framework. Angular wurde von Google als der neue Unterbau von deren Geschäftsanwendungen wie die GSuite gebaut. Komplexe und schnelle Interaktionen, und dabei den Entwicklern eben nicht nur Tools an die Hand geben, sondern auch Guidelines WIE etwas zu machen ist. Angular setzt dabei stark auf Komponenten (wie Delphi und z.B. Winforms / WPF auch) und lenkt den Entwickler sehr stark in die Richtung das ganze State-Handling über RX (reactive Extensions) zu machen, weil es hiermit sehr effizient wird genau herauszufinden, welche Teile des UIs neu gerendert werden müssen und welche eben nicht (Change detection), was zu einer deutlich besseren UI-Performance führt wenn man eben nicht in einer endlosen Timeline nur virtualisiert scrollen muss. Schreibst Du also Business-Anwendungen mit einer gewissen Komplexität wirst Du mit React früher oder später an die technischen Grenzen der Bibliotheksammlung kommen. Vue ist so ein zwischending und kann beides, aber weder das eine noch das andere so richtig gut. Dafür ist es leichtgewichtiger. Wenn Du also eine kleine Anwendung mit einer kleinen Handvoll Ansichten und nur begrenzten Interaktionsmöglichkeiten brauchst kann das funktionieren. Aber wehe die Anwendung wird dann irgendwann deutlich komplexer. Und ob ein Projekt morgen noch existiert kann Dir sowieso keiner verläßlich sagen. Da müssen nur die zwei, drei Hauptentwickler abends einen Trinken gehen und auf dem Weg dahin vom Bus überfahren werden.... Bei den Web-Frameworks und dem neuen .NET 5+ hat man den Vorteil, das das alles Open Source ist und jeweils sehr viele Firmen da ihre Anwendungen drauf aufbauen. Wenn Google morgen sagt, Angular wird nicht mehr weitergemacht (unwahrscheinlich, die schmeissen ihre neue GSuite eher nicht weg ;) also Busfaktor..., dann haben alleine wir in unserer Firma 3 Kollegen die Angular so im Detail kennen, dass sie in der Lage wären das weiter zu pflegen. Und viele unserer Kunden würden uns dann wahrscheinlich sogar dafür bezahlen wollen, weil deren Invest hoch genug ist um das nicht im Sande verlaufen lassen zu wollen. |
AW: Modernisierung von Legacy-Anwendungen
Busfaktor :lol: :lol: den muss ich mir merken
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
![]() |
AW: Modernisierung von Legacy-Anwendungen
Zum Thema "Delphi geht nicht unter" möchte ich mal Kylix, Delphi.NET und Delphi4PHP in den Raum werfen. Und zumindest meiner Meinung nach ist FMX auch nicht gerade der große Wurf.
|
AW: Modernisierung von Legacy-Anwendungen
Delphi4PHP? WTF? Das klingt ja schon nach Frankensteins Monster. Ist es allen erstes das was ich denke? Ist das allen ernstes Delphi welches von PHP Interpretiert werden kann? Davon höre ich grad das erste mal. Das konnte doch nur in die Hose gehen.
|
AW: Modernisierung von Legacy-Anwendungen
Strange. Ich frage nach Kolleg*innen, die Legacy-Apps modernisieren wollen + wir landen bei Frameworks aus anderen Welten. Hmm. Da haben doch einige mal die Entscheidung getroffen, weg von Delphi zu gehen. Würde ich zum jetzigen Zeitpunkt nicht machen - mit TMS Web Core - wurde ja schon genannt - gibt es ein echt spannendes Tool auch für Web Anwendungen.
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Hierfür scheint mir der Zustand der alten App wichtig. Noch wichtiger ist für mich die Frage: sind die Anforderung klar? Wenn die nicht eindeutig sind und es nur heißt "soll funktionieren wie bisher", dann kann man die Neuentwicklung gleich aufgeben. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Windows Forms Skype for Business Windows Phone Windows 10 IoT Core Microsoft Edge (original) Kinect Codeplex XNA Visual Basic SourceSafe MS Java VM Bob .... |
AW: Modernisierung von Legacy-Anwendungen
@MEissing Tja, wenn man nicht jahrelang braucht, um ausm Quark zu kommen, dann kann man auch schneller Frameworks und Produkte bauen und wieder deprecaten :stupid:
|
AW: Modernisierung von Legacy-Anwendungen
[OT] Und mit whataboutism kommt man ja überall durch :stupid: [/OT]
|
AW: Modernisierung von Legacy-Anwendungen
Hier ging's doch um React, Vue, Blazer... "Moderne" Frameworks und deren Langlebigkeit (oder auch nicht). Und du kommst mit Kylix, Delphi.Net und Delphi4PHP (ist "OK" als Einwurf) und schwadronierst dann von Whataboutism...
Lächerlich. Sorry. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Schaut euch in der Welt mal um und macht euch hier nicht gegenseitig runter. Von Erwachsenen intelligenten Menschen sollte man eigentlich etwas anderes erwarten. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Was erwartest du? Delphi war und ist super für die (Windows) GUI Entwicklung. Alles was jetzt so nach und nach gekommen ist funktioniert mit jeder Version auch immer besser, der Rest der Welt bleibt aber nicht stehen. Embarcadero läuft den Trends hinterher. Ich würde heute für eine grundlegende Modernisierung nicht mehr Delphi verwenden. An die modernen Sprachen und Technologien sollte man sich ruhig mal rantrauen. Swift, Kotlin und go sind kein Hexenwerk. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Wie oft man die Kollegen aus dem MS VS-Umfeld gesehen hatte das sie in dem einen Jahr auf DIE Zukunftstechnologie umgestiegen sind und 1-2 Versionen von VS war das schon wieder out und man sollte auf die nächste Technik umsteigen. Paradebeispiel sind hier die DB-Zugriffstechniken wie (zwischenzeitlich) schneller Wechselten als die Modetrends. Zitat:
Und im Umfeld der Javascript-Frameworks sind schon einige sehr schöne Techniken dabei, gegen die ein Delphi-Anwendung nicht ankommt wenn es heißt "Lauf im Browser, Smartphone, ...) "Lauf unter Windows" wird hier teilweise gar nicht mehr benötigt, da diese Geräteklasse über "Browser" abgedeckt wird. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Meiner Meinung nach ist Delphi unschlagbar im Bereich Windows GUI. Der Bereich Mobile und Backends ist grundsätzlich möglich, andere Technologien sind aber sinnvoller. |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
Ich behaupte das meine GUI's die von Delphi bei weitem Übertrumpfen ohne VCL soweit es geht ohne Hunderte von Komponenten auf der Form und reine Win32API. Soviel dazu. Zudem unabhängig von irgendwelchen Styles. Einfach ein paar png's deren Ästhetik abhängig vom jeweiligen Designer sind. Müssen nicht allen gefallen daher hat man die Möglichkeit diese als Skins darzustellen. Für jeden etwas also. Mitunter reicht ein einfaches ändern des Hintergrund schon aus wie du am Beispiel sehen kannst. Edit: Zudem hat es immer schon Styles in irgendeiner Form gegeben (nichts anderes als Skins) die zuerst mit Winamp sowie ich weiß eingeführt wurden. Auch gab es nachher einige Anwender Komponenten bsp. "DynamicSkinForm" für Delphi wo man die form entsprechend Design konnte. Das hat aber nichts mit Delphi Ansicht zu tun! Delphi hat keine besseren Gui's als andere Programmiersprachen nur weil man die Möglichkeit hat Styles(Skins) zu verwenden. Das kann ich wie du siehst ohne Verwendung der vcl.Forms + Hunderte von Komponenten + Styles |
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
So wie ich hier lese ist das alles nicht sehr ausgereift. Komponente verschieben sich wie von Geisterhand auf dem Formular und.. und.. und Kann nur besser werden die Frage die da wäre? Wann. Irgendwie widerspricht sich deine Aussage mit der Realität! Zitat:
|
AW: Modernisierung von Legacy-Anwendungen
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:36 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz