Delphi für .NET <> Delphi Win32

[sir-archimedes]

Hallo,

ich habe bislang alle meine Projekte mit Delphi für Win32 geschrieben. Nun überlege ich, ob ich ein neues Projekt direkt mit .NET entwickeln sollte.

Was für Vorteile hätte eine Entwicklung für .NET?

Als bislang größten Nachteil sehe ich einerseite das Fehlen einiger guter Tools/Libraries, wie der ReportBuilder und andererseits mein momentan recht geringer Kenntnisstand über .NET. Letzteres könnte ich natürlich durch Einarbeitung bald ausgleichen.

Grundsätzlich möchte ich die Dinge, die Borland mit ECOII einsetzt nicht nutzen (alleine schon, da mein D2006Pro da nicht alle Fähigkeiten hat). Daher sehe ich bislang noch keine große Motivation für mich .NET einzusetzen. Aber gute Argumente können das natürlich schnell ändern :-)

Gruß,
Dominik

[Bernhard Geyer]

Zitat:

Zitat von dominik.boehm

Als bislang größten Nachteil sehe ich einerseite das Fehlen einiger guter Tools/Libraries, wie der ReportBuilder

Es gibt genügend gute Biblitheken auch in .NET. Du kennst Sie nur nicht.

Zitat:

Zitat von dominik.boehm

Grundsätzlich möchte ich die Dinge, die Borland mit ECOII einsetzt nicht nutzen (alleine schon, da mein D2006Pro da nicht alle Fähigkeiten hat). Daher sehe ich bislang noch keine große Motivation für mich .NET einzusetzen. Aber gute Argumente können das natürlich schnell ändern :-)

Es gibt auch Alternativframeworks wie ECO III auch auf dem Markt. Jedoch ist die Frage ob die alle so mächtig sind.

Es kommt immer darauf an was du machen willst.


Überall lauffähig: Wird dann evtl. auch Java besser geeignet sein
Entwicklung PocketPC: Da gibts nur .NET
Lauffähig auch auf älteren PC: Würde ich Win32 bevorzugen, da nicht unbedingt alte Rechner .NET-Kompatible sein. Und wer will schon schuld sein wenn ein Rechner nicht mehr geht.
64-Bit lösung schnell nötig: .NET
Web-Lösung. ASP.NET ist hier sehr gut.

[sir-archimedes]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von dominik.boehm

Als bislang größten Nachteil sehe ich einerseite das Fehlen einiger guter Tools/Libraries, wie der ReportBuilder

Es gibt genügend gute Biblitheken auch in .NET. Du kennst Sie nur nicht.

Das stimmt natürlich - hatte nur dein Eindruck, dass es noch nicht so viel gibt. Und bislang weiß ich nur, dass eine erste Portierung von ReportBuilder auf .NET gescheitert ist... Aber ansonsten habe ich mich noch nicht so sehr mit den Komponenten für .NET beschäftigt.

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von dominik.boehm

Grundsätzlich möchte ich die Dinge, die Borland mit ECOII einsetzt nicht nutzen (alleine schon, da mein D2006Pro da nicht alle Fähigkeiten hat).

Es gibt auch Alternativframeworks wie ECO III auch auf dem Markt. Jedoch ist die Frage ob die alle so mächtig sind.

Habe mich da vertan - hatte ECO III mit ECO II verwechselt. Interessant fände ich hier die Möglichkeiten des Objekt-Relationalen Mappings, auf das ich schon lange gewartet habe. Allerdings kann das mein Delphi (da nur Pro.) nicht und eine größere Version sitzt zur Zeit einfach nicht drin.

Web-Anwendungen und Plattformunabhängigkeit ist bislang nicht relevant und wird wahrscheinlich (bei dem Projekt) auch längerfristig nicht benötigt.

Gibt es denn ansonsten gute Gründe es mit .NET und nicht mit Win32 zu machen? (Plane zur Zeit auch die Anschaffung von RemObjects/DataAbstract und dafür muss ich natürlich auch wissen, ob ich .NET einsetzen möchte).

Achja: lässt sich nicht das .NET-Framework auf quasi allen zur Zeit gängigen Windowsplattformen installieren? Denn dann werden ja auch ältere Rechner unterstützt...

[DelphiAndreas]

ich würd von .net die Finger lasse wenn du auf die "Vorteile" verzichten kannst die Bernhard genannt hat. Ich glaube das .net-Framework gibts erst ab Win98SE, Win32 läuft ja praktisch überall.

Wenns wirklich Plattformunabhängig sein soll wäre wohl wirklich Java das beste, habe da recht gute Erfahrungen gemacht.

[Elvis]

Ich kann generell empfehlen neue Projekte nur in .Net zu beginnen. Natürlich nur solange das auch sinnvoll ist. (Wird z.Bsp.: viel direkter Speicherzugriff benötigt macht .Net wenig bis keinen Sinn...)

ORPFs für .Net gibt es wie Sand am Meer (nHibernate, nDO, OpenACCESS oder nHibernate-basierte Lösungen wie ActiveRecord).

Nur kann ich es nicht wirklich empfehlen dabei auf Delphi.Net zu setzen:

• D.Net kennt keine namespaces.
  Es ist sogar so fies, dass jede andere Sprache die namespaces deiner Packages sieht, nur du selbst musst dich weiterhin mit Units rumärgern.
• D.Net hat nur einen Single pass compiler der weiterhin absolute Eindeutigkeit von Bezeichnern erzwingt. Das widerspricht oftmals .Net allgemein anerkannten guidelines...
• Es wird Dinge an deine Klassen hängen, die sie aussehen lassen wie D32 Klassen.
  IMHO ein totales no-go falls du APIs anbieten willst. (Sinnlose public member wirken einfach komisch...)
• D.Net hinkte bisher immer dem Rest hinterher (D2006 mit 1.1 erschien nachdem .Net 2.0 herausgekommen ist)

Mit Sprachen, die auf .Net maßgeschneidert wurden, lassen sich viele Dinge schneller und mit weiger Code lösen. (z.Bsp.: C# oder Chrome)

ReportBuilder gibt es einige, CrystalReports ist ganz nett.
Und .Net wird von MS ab Win2000 unterstützt. Es gibt eine Version für 98/NT4 aaber damit musste ich mich zum Glück nicht rumärgern...

Zu den Vorteilen von .Net gehören IMHO:

• Reflection
• Riesige BaseclassLibrary
  Man findet vieles bereits vorgefertigt in der FCL.
• Remoting/ASP.Net
• Interface basiertes DataBinding für GUIs.
  Man kann fast alles an ein Control binden, welche Interfaces man implementiert hat bestimmen wieweit diese Bindung geht.
• Sprachunabhängigkeit

[Bernhard Geyer]

Zitat:

Zitat von dominik.boehm

Achja: lässt sich nicht das .NET-Framework auf quasi allen zur Zeit gängigen Windowsplattformen installieren? Denn dann werden ja auch ältere Rechner unterstützt...

Nur ab W98 (SE) mit IE 5.01 und allen sonstigen für IE 5.01 nötigen Updates.
Teile von .NET 2.0 gibt es nur für XP/2003 (Avalon).

[sir-archimedes]

Hmm - ich denke ich werde dann wohl den Weg des geringsten Widerstandes gehen, und erst mal noch mit Win32 weitermachen. Ich glaube die Vorteile von .NET kämen bei dem Projekt nicht so sehr zum Tragen und wahrscheinlich fährt man auch mit Win32-Anwendungen noch relativ gut.

Ich habe einfach nicht die Zeit, mich in ein komplett anderes System einzuarbeiten. Das werde ich aber nachholen, sobald ich die Zeit dazu finde.

[dfried]

Zitat:

Zitat von dominik.boehm

Gibt es denn ansonsten gute Gründe es mit .NET und nicht mit Win32 zu machen? (Plane zur Zeit auch die Anschaffung von RemObjects/DataAbstract und dafür muss ich natürlich auch wissen, ob ich .NET einsetzen möchte).

Wenn du soweiso schon "planst" dieses Framework einzusetzen, dann lies dir doch mal noch den BLOG Eintrag zum Thema .net oder nicht .net durch.

[hanspeter]

Hallo,

ein neues Projekt würde ich nicht mehr auf W32/Delphi aufsetzen.

Ich meine das Net sich zwischenzeitlich bei MFC und VB Entwicklern durchgesetzt hat.
Spätestens mit der nächsten Windowsversion, wenn Net Bestandteil des Betriebssystems ist und
Teile der Funktionalität nur noch in Net und nicht mehr in einer W32 API zur Verfügung stehen
wird MS sein Ziel erreicht haben.
Das IX Sonderheft zu Net gibt im angelsächsischen Sprachraum eine Verbreitung von 50% der
Entwickler an.
Für Deutschland etwa 40 %.

Schaut man auf Gulp in die Projektstatistik, dann hat Net Java deutlich überholt.
Delphi hat auf Gulp noch nie eine große Rolle gespielt und dümpelt unter 1%.
Ich selbst entwickle kommerziell noch mit Delphi 32, sehe aber bei einer Reihe Firmen eine Absetzbewegung
in Richtung Net.

Delphi hat eigentlich von den Mängeln der MFC gelebt und war hier eine hervorragende Alternative.
Heute ist dieser Vorsprung verspielt.
Die VCL ist in die Jahre gekommen und jede neue Delphiversion seit D5 bringt soviele Kinderkrankheiten und
Geburtswehen mit sich, das ein kommerzielles Arbeiten erst nach dem 2. Update sinnvoll ist.
Dann kommt aber meistens auch schon die neue Version mit neuen Problemen.
Mit Andre Heiljberg ist der geistige Vater von Delphi zu MS gewechselt.
Die Erfahrungen mit Delphi haben viele Konzepte in der Net Welt geprägt.
Bei Erfahrungen mit Deplhi ist der Einarbeitungsaufwand geringer, als wenn man von typischen MS-Sprachen kommt.

Delphi und Net ist auch nicht die erste Wahl.
Wenn ich Net 2.0 mit Delphi das erste mal ausprobiere, hat die Konkurenz schon ein Jahr Erfahrung.

Fazit.
Ich meine die Blütezeit von Delphi ist vorbei.
Ich selbst benötige es nur noch um Altprojekte zu pflegen.
Schaue hier aber auch schon in Richtung Chrome und C2 (ein Delphi -> C# Konverter.)

Gruß

Peter

[peteress]

Zitat:

Zitat von Elvis

• D.Net kennt keine namespaces.
  

• Das kann ja so nicht sein. Eine Sprache, die keine Namspaces kennt, könnte z.B. auf keine einzige FCL Klasse zugreifen.
  z.B. VB
  imports System.Drawing
  C#
  using System.Drawing
  Delphi.Net
  uses System.Drawing
  
  Was also fehlt dir am Konzept der Namespaces?
  
  Zitat:

  Zitat von Elvis

  Es ist sogar so fies, dass jede andere Sprache die namespaces deiner Packages sieht, nur du selbst musst dich weiterhin mit Units rumärgern.

  D.Net hat nur einen Single pass compiler der weiterhin absolute Eindeutigkeit von Bezeichnern erzwingt. Das widerspricht oftmals .Net allgemein anerkannten guidelines...

  Bezeichner mussten in Delphi noch nie eindeutig sein. Ich kann in jeder Prozedur die Laufvariable der For Schliefe wieder i nennen, jede Klasse kann eine Methode execute haben, und selbst mehrere globale Variablen können dengleichen Namen haben. Innerhalb der Regeln für die Sprache, muß der Compiler natürlich eindeutig feststellen können, welcher Bezeichner denn eigentlich gemeint ist. Das hat auch eindeutig nichts mit dem Single oder Multipass Compiler zu tun. Nicht eindeutige Bezeichner werden durch mehrmaliges parsen des Quellcodes nicht eindeutiger. Das ist wie die alte Laborregel: Dreimal abgeschntten und immer noch zu kurz.
  
  
  
  Zitat:

  Zitat von Elvis

  Es wird Dinge an deine Klassen hängen, die sie aussehen lassen wie D32 Klassen.
  IMHO ein totales no-go falls du APIs anbieten willst. (Sinnlose public member wirken einfach komisch...)

  D.Net hinkte bisher immer dem Rest hinterher (D2006 mit 1.1 erschien nachdem .Net 2.0 herausgekommen ist)

Zitat:

Zitat von Elvis

Mit Sprachen, die auf .Net maßgeschneidert wurden, lassen sich viele Dinge schneller und mit weiger Code lösen. (z.Bsp.: C# oder Chrome)

Dass Delphi beim Compilieren (oder wann?), an Klassen public Members ranhängt. die im Quellcode noch nicht da waren, würde mich auch überraschen. Wieder die Frage, was soll das sein?
MS hat über drei Jahre mit 1500 Entwicklern an der Version 2.0 von Dot Net gebaut,und auch den eigenen Compiler dafür erst im letzten Quartal released. Ich denke, da kann man Borland schon noch ein paar Monate Zeit geben.

Gruss
Peter