Portierung von Delphi 7 Datenzugriff auf C#

Question

Wir haben eine in Delphi 7 geschriebene Client/Server-Anwendung mit einer Firebird-Backend-Datenbank. Der Code begann ursprünglich mit einer Datenzugriffsschicht, zerfiel aber schnell in den Datenzugriff in Formularen und verschiedenen Einheiten, die über das Projekt verstreut waren.

Wir möchten irgendwann in naher Zukunft auf .NET umsteigen, und meiner Meinung nach wäre es am besten, zunächst die DAL in .NET zu übertragen und die aktuelle Delphi-Anwendung zu implementieren. Dann können wir die Geschäftsschicht und schließlich die Benutzeroberfläche weiter portieren.

Also ich bin auf der Suche nach einigen Ideen von anderen Entwicklern auf einige Technologien/Frameworks in für die Verschiebung der DAL in .NET zu suchen. Mein erster Gedanke wäre es, einige Webdienste zu erstellen. Die Idee ist, die aktuelle Client/Server-Anwendung nach .NET zu verschieben. Wir können uns später mit Mehrschichtdesign und Webanwendungen beschäftigen. Vielleicht ist die richtige Antwort, von vorne anzufangen?

Für jeden Gedanken oder jede Idee wären wir Ihnen sehr dankbar.

Answer 1

Dafür gibt es kein Patentrezept. Ich bin auch ein Delphi-Entwickler, der jetzt in der .NET-Welt arbeitet.

Bei Delphi geht es um Extreme. In jeder Sprache kann es gut oder schlecht geschriebene Software geben. Aber wenn eine Anwendung in Delphi gut geschrieben ist, ist sie der Himmel. Wenn sie es nicht ist, ist sie die Hölle. Sie wissen, was ich meine. Delphi nimmt RAD auf eine ganz neue Ebene. So kann man Software wirklich schnell schreiben. Aber es wird unübersichtlich... Ähnlich wie bei WinForms, wenn Sie den SQL Insert-Befehl in das Button-Ereignis schreiben :)

Hier sind meine Gedanken:

• Wenn Sie sich für .NET entscheiden, dann bitte mit C#. Und schauen Sie nicht zurück.
• Sie sollten auf jeden Fall mit der Datenschicht beginnen.
• Wenn Sie Ihre Delphi-UI vorerst beibehalten und mit Ihrer .NET-DAL arbeiten, werden Sie sich vielleicht sogar wundern, dass Sie nicht zu WinForms wechseln wollen. Einige Leute könnten sich darüber aufregen, aber die Zeit wird es zeigen...
• Vielleicht möchten Sie Ihr DAL als WebServices implementieren. Es gibt eine Menge Lernmöglichkeiten auf beiden Seiten Ihrer Software. Und auch die Wiederverwendbarkeit ist gegeben!
• Beginnen Sie Ihr DAL von vorne. Sie werden es nicht bereuen.
• Beginnen Sie die Benutzeroberfläche nicht von Grund auf neu. Versuchen Sie, Ihre bestehende Benutzeroberfläche zu verwenden. UI braucht Zeit. Wenn Sie alle Ihre bestehenden Bildschirme überprüfen, werden Sie die schlechten Dinge loswerden und sich dann mit dem neuen .NET DAL verbinden. Aber alles von Grund auf neu zu entwickeln, ist überwältigend und könnte das Team auf lange Sicht deprimieren.

Answer 2

Sie können verwenden Delphi Prisma .
Es ist nicht wirklich Delphi, sondern Object Pascal für .NET.

Die Portierung von Delphi nach Prism wird jedoch viel einfacher sein, da es sich um Pascal handelt und Embarcadero sich bemüht hat, den Übergang zu erleichtern.

Da es .NET und nicht VCL verwendet, ist es no eine einfache Neukompilierung, aber man kann viel mehr Dinge wiederverwenden, als man es sonst tun würde.

Answer 3

Das sieht aus wie etwas, wo DataAbstract nützlich sein kann. Es bietet Unterstützung für .Net und Delphi (und mehr, Java ist bereits in Vorbereitung).

Es würde erlauben, den Server mit C# zu erstellen und die Delphi-Clients über die DA-Middleware zu verbinden.

In einem ersten Schritt könnte Ihre Anwendung in eine Delphi-basierter Server und Client und wenn die C/S-Kommunikationslogik funktioniert, können Sie einen entsprechenden Server in C# erstellen und dann wechseln.

Ich will damit nicht sagen, dass dies eine gute Idee ist, sondern nur zeigen, dass es technisch gesehen einen einfachen Weg gibt. Der Grundgedanke von Abstraktionsschichten und Middleware besteht darin, hinsichtlich der eigentlichen Implementierung flexibler zu sein.

Answer 4

Ich befinde mich in einer sehr ähnlichen Situation. Siehe Frage

Zuerst wollte ich WCF verwenden, aber der Delphi-WSDL-Importer konnte es einfach nicht. Jetzt verwende ich ASP.net-Asmx-Webdienste, und die Interoperabilität hat sich erheblich verbessert.

Wir führen eine schrittweise Migration von einem Thick Client mit inkonsistentem Inline-SQL, gespeicherten Prozeduren und bis zu 900-1200 Zeilenmethoden zu einer mehrschichtigen Lösung durch. Sobald die serverseitige Funktionalität vorhanden ist, gehen wir dazu über, die Änderung im Delphi-Client zu implementieren. Auf diese Weise kann die bestehende Anwendung weiter funktionieren, und die Tests und die Bereitstellung können schrittweise erfolgen.

Ich habe mit der Implementierung der DAL begonnen, und mit Hilfe des Entity-Frameworks haben wir alle unsere Datentabellen als Entitäten dargestellt und tauschen Daten mit dem Client über Datentransferobjekte für jede Entität aus.

Als nächstes wird die Geschäftslogik Funktionsbereich für Funktionsbereich migriert, und schließlich wird der Client einfach das tun, was ein Client-Formular tun sollte, nämlich dem Benutzer die Interaktion mit der Anwendung ermöglichen.

Einer der Hauptgründe, warum wir uns für EF entschieden haben, war, dass Visual Studio die Delphi-Klassen automatisch generieren kann, mit Änderungsverfolgung (daran arbeiten wir noch) und Datenpersistenzlogik, indem wir t4-Vorlagen optimieren.

Es gibt noch einen Haken: Datenbindung auf dem Client von einem .Net-Webdienst ist immer noch unmöglich mit Delphi 2010. Wir werden dies daher bis zum Schluss aufschieben.

All dies wird uns in die Lage versetzen, maßgeschneiderte Kundenwünsche schneller auf dem Server umzusetzen, ohne das Client-Design zu untergraben.

Diejenigen, die sich fragen, warum das so ist, und darauf bestehen, dass es immer eine schlechte Idee ist, sollten bedenken, dass in einigen Fällen (wie bei mir) diese gut genutzten Anwendungen sehr komplex sind und nicht alle Delphi-Entwickler noch da sind, um fragwürdige Design- und Programmierentscheidungen zu rechtfertigen. Derzeit ist das Hinzufügen neuer Funktionen immer ein Glücksspiel, wenn Variablen mehrere Bedeutungen haben, und für eine Anwendung dieser Größe ist die IDE von Delphi 2010 unzureichend, was die Wartung zu einem echten Problem macht, wenn man von Visual Studio kommt. Verstehen Sie mich nicht falsch, ich habe Delphi gelernt, um diese Entwicklung zu übernehmen, aber die Art und Weise, wie dieses historische Produkt geschrieben wurde (in Delphi 5), ist völlig unhaltbar.

Die Frage ist nicht, warum, sondern in vielen Fällen: Wie lange können Sie es sich leisten, das Problem zu ignorieren, bevor Sie gezwungen sind, eine umfassende Überarbeitung vorzunehmen oder das Produkt aufzugeben?

Answer 5

Auch wenn ich der Meinung bin, dass Neufassungen immer ein Fehler sind, können Sie genauso gut dort beginnen, wo Sie bei jedem Technologieversuch beginnen würden: Erstellen Sie einen Prototyp. Installieren Sie Firebird ADO.net Konnektoren und schreiben Sie Ihre DAL in C#.

Eine bestehende Anwendung neu zu schreiben ist immer mehr Arbeit, als nur die aktuelle Anwendung zu reparieren. Immer. Und am Ende verlieren Sie die Portabilität, statt sie zu gewinnen.

Wenn ich eine Delphi-Anwendung in etwas anderem neu schreiben würde, und es wäre nicht einmal nativer Code, dann wäre es Java, nicht .net. Trotzdem wiederhole ich meinen ersten Punkt: Rewrites sind Zeit- und Geldverschwendung, und in jedem realen Unternehmen, in dem ich sie je in Erwägung gezogen habe, waren sie IMMER ein Fehler. Und doch entscheiden sich die Leute immer wieder dafür, es zu tun.