Von Delphi zu Net

[Carla]

Hallo,

da ja Codegear Delphi-Net wohl auf das Abstellgleis geschoben hat,
möchten wir jetzt den Wechsel von Delphi (Win32) zu Net und VS2008 vornehmen.
Auch wenn wir eingefleischte Delphi-Programmierer überzeugen müssen, ist dieser Weg wohl notwendig, da ich den Eindruck habe, das man sich mit Delphi
etwas vom allgemeinen IT - Fortschritt abgekoppelt hat.
Mich würde interessieren wer diesen Schritt bereits vollzogen hat und
wie die Erfahrungen mit dieser Umstellung sind.
Wie schätzt ihr die Entscheidung zu einem Systemwechsel im nachhinein ein?

Mit Gruß
Carla

[markus lemcke]

mache es nicht!!! *schallendlach*

Also, ich hatte jetzt nicht die Aufgabe ein Delphi-Projekt in C# umzuschreiben, aber ich war jahrelangf begeisterter Delphi-Fan und weil es keine jobs/Aufträge mehr gab bin ich zu C# gewechselt!

Das .net-Microsoft-Monster ist mit Sicherheit nicht schlecht und auch wenn ich immer wieder mal schimpfe, inzwischen mag ich es (wenigstens bißchen )

Das Problem ist die Komplexität! Es ist so mächtig und so umfangreich, es geht nicht einfach so g'schwind! Ich habe mir 4 Bücher über C# 2008 gekauft, alle haben mindestens 1000 Seiten und bestimmte themen (z.b. netzwerk-Programmierung) kommt in keinem der 4 Bücher!!!

Die Hilfe von Microsoft ist stark gewöhnungsbedürftig und mir als verwöhnter Delphianer fehlen Codebeispiele!

Datenbank-Programmierung ist in Delphi locker, easy, relaxt und entspannt in .net fast eine Wissenschaft!

Resümmee:
Wie bei allem was Microflop macht, wird .net sich durchsetzen, aber der Umstieg wird hart und langwierig!!!

[Bernhard Geyer]

Bei einem Wechsel einer Programmiersprache bzw. des Frameworks sollte immer hinterfragt werden welche Vorteile man sich verspricht. Ein Delphi.Win32-Programm in ein .NET-Winforms-Programm umzusetzen bietet dem Kunden keinerlei Vorteile und kosted dem Entwickeler/Hersteller jede menge Zeit+Geld. Falls man ein Programm portieren will sollte man am besten noch 2-3 Schritt weiter zurückgehen und auch gleich das Design/Architektur des Produktes begutachten:

- Wird noch eine Windows-Desktop-Anwendung benötigt?
- Welche Schnittstellen will man in Zukunft bedienen (jetzt Vendor-Lockin mit nur eine DB, neues System z.B. mit (N)Hibernate DB-Neutral
- Welche Clients (PC/PocketPC/NetBook/Linux/Windows/MacOS/Smartphone) sollen bedient werden
- Welche Bedienphilosphie wäre besser?

Und bitte nicht nur .NET als Alternative ansehen. Evtl. ist ja Java/PHP/... besser geeignet.

[gfoidl]

Hallo Carla,

ich stieg vor ca. 1 Jahr von Fortran und von VB auf .net (C#) um. Der Umstieg bzw. das Neulernen der Sprache viel mir nicht schwer. Es stimmt dass das Framework eine Unzahl an Methoden bereitstellt. Je nach Anwendungsgebiet bzw. benötigten Methoden muss man sich dann informieren/einarbeiten - es gibt genügend Info im Netz zu finden (zB dieses Forum)

Der Umstieg ist nur dann schwierig und langwierig wenn versucht wird eingebaute Komponenten von Delphi in C# 1:1 zu übernehemn bzw. nachzuahmen. In C# gibt es andere Möglichkeiten dies zu erledigen. D.h. es muss eine andere Denkweise als in der alten Sprache verwendet werden.

Datenbankzugriff ist in .net kein Problem (zugegebenermaßen wenn der hauseigene SQL Server verwendet wird). ZB mit LINQ (sprachintegrierte Abfragetechnik) können Objekte aller Art, dazu zählen auch Datenbanken, sehr einfach bearbeitet werden. Die Bindung der Daten an GUI-Elemente wird großteils vom Designer in Visual Studio unterstützt.

Ein (für bestimmte Fälle) Pluspunkt von .net ist dass die gleiche Logik sowohl für Windows- als auch für Webanwendungen verwendet werden kann.

Ob sich ein Umstieg lohnt kann ich nicht beantworten. Gewiss ist jedoch dass Microsoft mit der .net-Ifizierung fortsetzt und deshalb wird es sich wohl durchsetzen.

mfG Gü

[Ralf Jansen]

Hi,
ich selbst habe knapp 10 Jahre Delphi Erfahrung und mache seit dem erscheinen des Framework 2.0 eigentlich nur noch NET Entwicklungen(C# habe aber auch VB und Chrome in echten Projekten probiert).

Umstellung finde ich ist ein blöder Begriff in dem Zusammenhang, es ist eine Weiterbildung. Kein Entwickler sollte sprachlich nur auf ein Pferd setzen und sich möglichst in mehreren Gebieten auskennen. Wenn es hauptsächlich um Windowsentwicklung geht finde ich sollte man ein Standbein in Win32 Entwicklung und in NET haben. Delphi und C# sind da 2 hervorragende Kandidaten.

Delphi.Net ist wirklich nicht zu empfehlen. Ich würde auch von VB und Chrome(bzw. Oxygene) abraten. Die Unterstützung über das Internet ist mit C# einfach am größten und (zumindest gefühlt) am professionelsten. Die eigentliche Lernhürde, das Framework mit sein Sprachfeatures stellt, sich in allen Derivaten ähnlich dar. Die klassischen Streitereien zwischen C-style und pascal-style Sprachen ('Klammern sind Mist ich will Begin end' oder mein Lieblingsspuch 'Iehh! Da gibts keine Datamodules wie soll ich da sauber Buisnesslogik kapseln') sind nur Lappalien und schnell erledigt. Bei Leute die daran scheitern habe ich Probleme die Softwareentwickler zu nennen.

Wenn man die Framework, Sprachfeaturehürde genommen hat und ein Gefühl fürs Framework bekommt, nicht mehr nach äquivalenten Techniken aus der Delphiwelt sucht ganz einfach weil NET andere (meist bessere und modernere) Konzepte umgesetzt hat will man eigentlich nicht mehr zurück.

Wenn du mit Umstellung aber meinst ein Entwicklerteam und eine spezielle über Jahre gewachsene Anwendung umzustellen würde ich ungesehen abraten bzw. euch raten das genau zu überlegen. Erstens der größte Vorteil hinter NET ist Produktivität. Die Software wird weder schlechter noch besser dadurch das sie in NET programmiert wird. Eine Softwareumstellung kostet also erstmal nur Zeit ohne sichtbaren Gewinn(aus Anwendersicht) Und zweitens habe ich bei mehreren Jobs ein gewisses negatives Momentum gesehen das schnell gegenüber NET Anwendungen entsteht weil sie eben gegenüber Win32 Anwendungen nicht nur Vorteile sondern auch Nachteile haben. So sachen wie längere Startuptime der Anwendung oder nicht mehr so simples Deployment über eine reine Serverinstallation werden schnell zum riesigen Problem hochgekocht wenn nicht alle hinter der NET Initiative stehen.

[Carla]

Erst mal vielen Dank für die Meinungen. Hilft mir bei der Entscheidungsfindung schon weiter.
Wir haben ein größeres Projekt, samt Entwickler, von einer Firma übernommen.
Dieses Projekt bedürfte dringend eines Redesigns. Gerade mit Delphi gibt es Probleme bei der Modularisierung. Das BPL Konzept ist ein Krampf. Auch wenn ich mit dll arbeite, benötige ich das Laufzeitsystem als BPL.
Viele Tools, welche zugekauft und in dem Programm verwendet wurden, stagnieren oder wurden seit Delphi6/7 nicht mehr weiterentwickelt.
Wir selbst arbeiten noch mit Delphi 7. Da ohnehin ein Redesign ansteht, soll der Wechsel des Programmiersystems eigentlich aus Effizienz-Gründen erfolgen.
Ich habe den Eindruck, das das kommerzielle Umfeld bei Net/C# inzwischen deutlich größer ist. Langfristig wird Codegear wohl nicht an einer NET Einbindung vorbeikommen.
Leider hält sich die Firma, was Entwicklungsrichtung angeht so bedeckt, das man darauf keine
Planung aufsetzen kann und es sicherer ist, den Anbieter zu wechseln.


Gruß Carla

[Bernhard Geyer]

Gerade mit Delphi gibt es Probleme bei der Modularisierung. Das BPL Konzept ist ein Krampf. Auch wenn ich mit dll arbeite, benötige ich das Laufzeitsystem als BPL.

Was spricht dagegen zwar auf Sourcecode-Ebene schön zu modularisieren aber dann alles als eine Exe auszuliefen?

Viele Tools, welche zugekauft und in dem Programm verwendet wurden, stagnieren oder wurden seit Delphi6/7 nicht mehr weiterentwickelt.

Hier liegt vermutlich 2 Probleme vor:
- Wildwuchs der eingesetzten Komponenten. Statt sich auf eine Handvoll Komponentenpackages zu beschränken (eins für GUI, eins für DB-Zugriff, ...) wurde vermutlich für Grid aus Sammlung x zugegriffen, Buttton aus Sammlung y, ....
- Kapslung: Alles was nicht GUI-Lastig ist kann man sehr schön Kapseln so das ein wechsel der Komponente nicht änderungen in jeder Unit benötigt (Hab mit Kapslung im DB-Bereich die Kompos für MySQL-Zugriff in 2 Tagen getauscht).

Ich habe den Eindruck, das das kommerzielle Umfeld bei Net/C# inzwischen deutlich größer ist.

Sicherlich ist es größer. Vieles was früher MFC/ATL und C++ im Windows-Umfeld war (war damals auch größer) ist jetzt C#/.NET. Jedoch ist der Produktivitätsnachteil von MFC/ATL gegenüber der VCL jetzt mit .NET nicht mehr gegeben.

Langfristig wird Codegear wohl nicht an einer NET Einbindung vorbeikommen.

Sie hatten schon mal sehr stark auf .NET gewechselt und dabei den nativen Teil vernachlässigt. Leider war/ist der .NET-Port nicht gerade das Gelbe vom Ei.

Leider hält sich die Firma, was Entwicklungsrichtung angeht so bedeckt, das man darauf keine Planung aufsetzen kann und es sicherer ist, den Anbieter zu wechseln.

Wird mit neuen Eigentümer jetzt Hoffentlich besser. Borland als Ex-Eigentümer will ja nix mehr mit SW-Entwicklung zu tun haben sondern nur noch mit dem Drum-Herum (Was sicherlich auch wichtig ist) und Beratung leisten. Aber ein Organismus ohne Herz (und das war bei Borland mal die IDE-Abteilung) wird nicht überlebensfähig sein.


Gruß Carla[/QUOTE]

[Carla]

Hier liegt vermutlich 2 Probleme vor:
- Wildwuchs der eingesetzten Komponenten. ...

Nicht unbedingt.
z.B. IBObjects stagniert seit August 2007, hat Probleme mit Fb2.1 und ist eine
sehr probitäre Lösung.
Wird jetzt mit IBDAC abgelöst.

Z.Zt. setzen wir in der gesamten Oberfläche auf TMS - Komponenten und lösen alle sonstigen ab.
TMS hat aber viele kleine ärgerliche Bugs und ist in sich nicht ganz durchgängig
gelöst (Styles).
Modularisierung ist eigentlich gedacht um Aufgabenbereiche/ Entwickler zu trennen.
Die übernommene Lösung modularisiert auf Basis von EXE-Files. Diese kommunizieren über TCP/IP.
Das hat unter anderen auch einen psychologischen Effekt. Bei einer Änderung wird nur eine Exe ausgeliefert. Das eigentliche Programm bleibt unverändert.
Wir schleppen halt nur mit jeder Exe etwa 2 MByte gelinkte Laufzeitbibliothek mit.

Gruß
Carla

[Bernhard Geyer]

Nicht unbedingt.
z.B. IBObjects stagniert seit August 2007, hat Probleme mit Fb2.1 und ist eine
sehr probitäre Lösung.
Wird jetzt mit IBDAC abgelöst.

Das Problem mit sterbenenden Komponenten hast du auch unter .NET/Java/.... Das wichtigst ist das du Sourcecode bekommst um in diesem Fall auch noch fixes/anpassungen vornehmen zu können.

[Carla]

!

Die Hilfe von Microsoft ist stark gewöhnungsbedürftig und mir als verwöhnter Delphianer fehlen Codebeispiele!

Dann hast Du aber lange nichts mehr mit Delphi gemacht?

Delphi verwendet inzwischen die MS - Hilfe. Hat diese aber noch wesentlich
verschlimmbessert. Wenn mann nicht weis was man sucht findet man überhaupt nichts und wenn doch dann erst mal hunderte Treffer für Net.
Und was sind Codebeispiele?
Die sind ab Delphi 7 aufwärts Geschichte.

Gruß
Carla

[markus lemcke]

Hallo Carla,

stimmt, ist ca. zwei Jahre her und es war Delphi 6!

was codebeispiele sind? das hier:

var

  FromF, ToF: file;
  NumRead, NumWritten: Integer;
  Buf: array[1..2048] of Char;
begin
  if OpenDialog1.Execute then             { Dialog zum Dateiöffnen anzeigen }
  begin
    AssignFile(FromF, OpenDialog1.FileName);
    Reset(FromF, 1);	{ Datensatzgröße = 1 }
    if SaveDialog1.Execute then           { Dialog zum Speichern anzeigen }
    begin
      AssignFile(ToF, SaveDialog1.FileName);	{ Ausgabedatei öffnen }

      Rewrite(ToF, 1);	{ Datensatzgröße = 1 }
      Canvas.TextOut(10, 10, 'Kopieren von ' + IntToStr(FileSize(FromF))
        + ' Byte...');
      repeat
        BlockRead(FromF, Buf, SizeOf(Buf), NumRead);
        BlockWrite(ToF, Buf, NumRead, NumWritten);
      until (NumRead = 0) or (NumWritten <> NumRead);
        CloseFile(FromF);
        CloseFile(ToF);
    end;
  end;
end;

ruckzuck gefunden (allerdings Delphi 5!!!)

[Carla]

Hallo Carla,

stimmt, ist ca. zwei Jahre her und es war Delphi 6!

was codebeispiele sind? das hier:

sorry,
ich weis schon was Codebeispiele sind.
Ich wollte eigentlich nur ausdrücken, das Codegear die seit D2005 abgeschafft hat.

Gruß
Carla

[jacky.net]

Hallo Carla,

ich selbst vollziehe gerade einen solchen Wechsel. Anbei einmal meine Überlegungen zu diesem Schritt:

Die folgenden Aussagen beziehen sich auf Delphi 5/7, welches ich selbst ca. 10 Jahre genutzt habe.

1. Es können recht schnell native Windows Anwendungen erstellen. (+)
2. Die Programmiersprache Delphi ist einfach. (+)
3. Es existieren sehr viele OpenSource/Kaufkomponenten auf dem Markt. (+)
4. Großes Problem: Keine durchgängige Unicode Unterstützung (-)
5. Großes Problem: Immer noch keine 64 Bit Unterstützung. (-)
6. Keine modernen und sinnvollen Sprachkonstrukte (Interfaces, Generics, Foreach) usw. was alle anderen modernen Programmiersprachen haben. (-)
7. Eine nur sehr einfache IDE. kein Refactoring, Keine Unterordner in Projekten ... (-)
8. GRÖTES PROBLEM: Ungewissheit. Es kommen keine definitiven Zusagen von Codegear. 64 Bit wurde mehrmals verschoben. Was ist wenn Windows 7 kommt? Was ist wenn es bald 128 Bit Systeme gibt? (-) Kommt Codegear dann noch nach?

Ich habe auch eine ganze Zeit lang in Java entwicklet. Dazu wurde Eclipse als IDE eingesetzt. Selbst das war ein riesen Fortschritt zu Delphi. Richtige Interfaces und nicht wie in Delphi solchen merkwürden COM Konstrukte. Aber das nur am Rande.

In unserem Unternehmen haben wir einige Millionen Zeilen ObjectPascal. Die können und dürfen natürlich nicht einfach ignoriert werden. Ein Austausch oder eine Portierung nach C# würde Jahre dauern. Kosten (hoch). Nutzen (gering). Frust (groß). Kunden (nichts neues).

Es spricht aber nichts dagegen, NEUENTWICKLUNGEN in einer neuen Programmiersprache wie C# zu machen. Diese Neuentwicklungen können auch aus Delphi genutzt werden, indem um den C# Code eine COM Schnittstelle gelegt wird. Die andere Richtung ist auch möglich. So kann Bestandscode in der C# Anwendung genutzt werden. Ist zwar kein "Pure .NET", aber es läuft. Den Kunden interessiert es sowieso nicht.

Wenn euer Unternehmen nur den Windows Markt addressiert, dann kann der C# Code sowohl für Windows Client Anwendungen, Windows Web Anwendungen (ASP.NET) und für die Integration in Microsoft Office Anwendungen genutzt werden. Das ist ein wichtiger Aspekt. Diese Möglichkeit der Wiederverwendung spart Zeit und Geld. Bugs wird es immer geben, aber es ist gut wenn der Bug nur EINMAL behoben werden muss.

Den Lernaufwand für den Umstieg von der Programmiersprache Delphi nach C# halte ich für gering. Die Sprache wurde vom gleichen Mann designed. Das merkt man auch beim Entwickeln. If Then Else unc Co. gibt es fast überall, nur die Schreibweise variiert.

Aufwendig ist jedoch die Einarbeitung in die ganzen Klassenbibliotheken um das .NET Framework herum. Allein das Verständis für die Zusammenhänge im Hintergrund kostest Zeit und Geduld (IL,NGEN,GAC,Assembly und Co.).

Gruß, Dieter

[Bernhard Geyer]

@jacky.net

zu 4: Wird in ein paar Wochen durchgängig sein (Delphi 2009). Evtl. für USA schon nächste Woche.

zu 5: Soll/Wird mit Delphi 2010 in 2009 kommen. Aber was ist das große Problem daran? Braust du wirklich im Prozesse mehr als 3GB?

zu 6: Interface seit Delphi 3 vorhanden (Mit automatischer Referenzzählung und nicht nur "Smart Interfaces"). Generics kommen mit Delphi 2009 für Win32 (In .NET schon seit D2006 vorhanden). ForEach weiß ich nicht ob da was angedacht ist.

zu 7: Refactoring in neuen (D200x) Versionen vorhanden. Für alte Versionen per Plugin von diversen Herstellern nachrüstbar. Was meinst du mit Unterordner in Projekten?

Hier ein Übersicht der größten Blöcke die bei neueren Delphi-Versionen dabei sind. Wenn man schon vergleicht (D5/D7) sollte man mit entsprechend alten Versionen von MS vergleichen wie VB 6 oder Visual Studio 6 bzw. (D7) VS.NET 2002. Es stimmt das mit MS mit .NET mehr als aufgeholt hat (mit MFC/ATL wären sie in vielen Bereichen nicht mehr weit gekommen).

[jacky.net]

Hallo Berhard,

ich habe mich mit Absicht auf Delphi 7 bezogen, da Carla das derzeit verwendet. Wenn ein Umstieg von Delphi 7 nach .NET gemacht wird, dann würde eine aktuelle Version von Visual Studio verwendet werden. Das wären dann gravierende Änderungen in der IDE, im Vergleich zu Delphi 7.

Aber du selbst hast es auf den Punkt gebracht. Deine Sätze fangen sehr oft mit "soll" oder "wird" an. Wir benötigen gewissen Feature bereits "In der Vergangenheit".

Zum 64 Bit kann ich nur sagen, dass es nicht um den Speicher geht, sondern vielmehr um die Verwendung von "32 Bit Delpi Code" in "Reinen 64 Bit" Umgebungen wie Beispielsweise "Sharepoint auf 64 Bit Windows". Und hier ist es ein Problem.

Aber in diesem Thread geht ja auch nicht so sehr um Delphi sondern vielmehr um den Umstieg.

Gruß, Dieter