C# vs. Delphi.NET II

[Matthias Schröder]

Hallo,

nachdem ich mit Interessse den Beitrag "[C#][Delphi] Vor und Nachteile" (http://www.delphipraxis.net/internal...ct.php?t=94094) gelesen habe, bleiben für mich immer noch ein paar Fragen offen. Ich bin in einer ähnlichen Situation, wo entschieden werden soll, ob mit Delphi.NET oder C# programmiert werden soll. Da ich seit 4 Jahren in C# programmiere, würde ich natürlich auch weiterhin gerne in C# implementieren. Da im Gegensatz zu früher jetzt eine Oracle DB verwendet wird, bin ich mir nicht ganz sicher welcher .NET Provider da am Besten für geeignet ist. Unter Visual Studio kämen da ODP.NET oder OraDirect.Net (was leider kostenpflichtig ist) zur Auswahl und mit dem BDS 2006 würde man ja wohl den BDP.NET Provider nehmen. Oder liege ich da falsch? Weiß jemand näheres zur Performance dieser Provider? Ich habe mal von einer Messung aus dem Jahr 2004 gelesen, da hat der BDP ganz schlecht abgeschnitten, aber das war wohl noch aus der Zeit wo dieser Provider noch kein Connection Pooling unterstützt hat.

Also prinzipiell würde ich ja lieber in C# programmieren. Aber mir fehlen irgendwie die schlagkräftigen Argumente für diese Sprache, zumal im BDS 2007 ja auch eine .NET 2.0 Unterstützung vorhanden ist. Es soll eine Windowsanwendung programmiert werden. Da ist Delphi ja eigentlich ey besser, oder sehe ich das falsch? Naja das stößt wohl wieder eine Grundsatzdiskussion an.... Wichtig wäre für mich erst einmal zu wissen, wie es um die .NET Data Provider bestellt ist.

Vielen Dank im Voraus und beste Grüße
Matthias

[Jürgen Thomas]

Hallo,

wenn Du an C# gewöhnt bist, bleib doch dabei. Mit NET 2.0 bist Du auf dem Laufenden. (Bei Delphi darfst Du noch warten.)

Zu Deiner eigentlichen Frage: Gehört der Oracle-Treiber nicht zu NET dazu? Bei mir ist er jedenfalls automatisch installiert (in machine.config); und ich habe nichts dazu manuell gemacht:

XML-Code:

<add name="OracleClient Data Provider"   invariant="System.Data.OracleClient" 
               description=".Net Framework Data Provider for Oracle"    
               type="System.Data.OracleClient.OracleClientFactory, System.Data.OracleClient, 
               Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>

Gruß Jürgen

[Matthias Schröder]

Hallo Jürgen,

danke für die rasche Antwort. Mitunter einer der Gründe, warum ich mich heute hier registriert habe. :thumb:
Also zurück zu den Providern. Du hast Recht, ein Oracle .NET Data Provider ist standardmäßig vorhanden. Da dieser aber von Microsoft ist, kann man da nicht allzu viel von erwarten. Oracle hat sodann seinen eigenen .NET Data Provider auf den Markt geschmissen (ODP.NET), welcher um Längen performanter sein soll. Unterstützt halt viele DB spezifischsen Features (z.B. Datentyen wie REF Cursors, LOBs, BFiles etc., RAC Unterstützung). Fragt sich nur, ob der BDP.NET Data Provider noch performanter ist und die IDE Integration vielleicht noch eleganter ist.
Gruß Matthias

[Phoenix]

Ich schiebe die Frage zu den Providern mal dezent weiter an Elvis ;-)

Nein, im Ernst: Ich hab gute (sogar sehr gute) Erfahrungen mit den CoreLabs Dataprovidern für Ora gemacht. Klar kosten die, sind aber ihr Geld wert.

Ansonsten: Wenn Du schon fit in C# bist spricht nichts, rein gar nichts dagegen das in C# zu machen. ;-)

[Phoenix]

Zitat:

Zitat von Matthias Schröder

Fragt sich nur, ob der BDP.NET Data Provider noch performanter ist und die IDE Integration vielleicht noch eleganter ist.

Es mag eleganter aussehen, ist es aber nicht. Und nein, sie sind nicht performanter ;-)

[Matthias Schröder]

Danke Phoenix, dann bin ich mal auf Elvis' Meinung gespannt. :wink:
Ergänzend muss man dazu sagen, das in unserem Team noch 2 Delphi Entwickler sind, die bisher jedoch noch nicht in Delphi.NET programmiert habe. Daher auch die Diskussion, was in Zukunft verwendet werden soll. Diese beiden Entwickler müssten demnach auf C# oder Delphi.NET umsteigen, oder alternativ ich eben auf Delphi.NET. Daher suche ich nach k.o. Kriterien, wo ich dann guten Gewissens behaupten kann, die richtige Entscheidung getroffen zu haben. Was is halt verhindern will ist, dass wenn wir C# verwenden, die beiden Delphi Freaks, bei jeder 2. Zeile Code aufstöhnen und sagen, "also das ist bei Delphi aber besser.." oder "gibts schon seit Jahren"...
Ich suche schon seit mehreren Tagen im Web nach kräftigen Argumenten für das eine oder andere. Letztendlich bin ich dann bei den .NET Data Providern gelandet, welche ja einen wesentlich Teil der Preformance ausmachnen.
Gruß Matthias

[Elvis]

Zitat:

Zitat von Phoenix

Ich schiebe die Frage zu den Providern mal dezent weiter an Elvis ;-)

Hehe, die Wahl des richtigen Oracle Providers ist ein wenig knifflig.
Der MS Provider wird bereits mit der Maschine installiert, aber scheint absichtlich abgebremst zu sein. Er taugt aber für Dinge, die entweder nicht performancekritisch sind und keine Ora spezifischen APIs benötigen.
Der ODP ist der schnellste von allen, aber er ist leider, wie alles was Oracle seit 8.17 auf den Markt geschmissen hat, ziemlich buggy und besitzt selbst in der aktuellen Version noch ein paar kleinere Mem-Leaks. (die sich bei einem Service innerhalb von Stunden übel auswirken können ;) )
Der Provider von CoreLabs sieht sehr schnieke aus. (kenne ihn nur von einem Fremdprojekt, bei dem ich etwas Feintuning vorgenommen habe (nein, nicht von dir Seb ;) ) )
Er ist nicht so schnell wie der ODP, aber schneller als der von MS. Außerdem hast du dort die Möglichkeit ohne Client/OCI direkt per TCP auf die Datenbank zuzugreifen. Das vereinfacht Deployment und könnte theorethisch die Sicherheitsanforderungen dramatisch herabsetzen.
Aber die Direct-Option kostet auch wieder etwas Performance gegenüber OCI.
Man hat natürlich bei allen 3 Providern die Möglichkeit ohne Client installation mit dem InstantClient eine OCI benutzen zu können. (Den Weg gehe ich selbst)
Gerade der letzte Punkt (mehrere MB InstantClient vs CoreLabs Direct), könnte wichtig sein. Oracles Installer haben einfach immer wieder gezeigt wie abartig sie mit dem Zielsystem umgehen. Einen richtigen OracleClient will heutzutage wohl keiner mehr freiwillig auf seiner Maschine haben. :mrgreen:

[hanspeter]

Zitat:

Zitat von Matthias Schröder

Ergänzend muss man dazu sagen, das in unserem Team noch 2 Delphi Entwickler sind, die bisher jedoch noch nicht in Delphi.NET programmiert habe. Daher auch die Diskussion, was in Zukunft verwendet werden soll. Diese beiden Entwickler müssten demnach auf C# oder Delphi.NET umsteigen, oder alternativ ich eben auf Delphi.NET. Daher

Ich arbeite seit TP 1.0 mit TP/Delphi und meine Meinung für Neuentwicklungen lass die Finger von Delphi.

Die Gründe sind schon vielfältig aufgezählt und stellen nur eine Wiederholung dar.

Nur kurz:
- Seit D8 praktisch unbrauchbare Hilfe - alle Beispiele verschwunden.
- SDK Stand 2003.
- VCL.Net ist eine Krampflösung unter Mono nicht oder nur eingeschränkt lauffähig.
- technologischer Rückstand > 1 Jahr, kommt VS2007 mit 2.0, dann ist C# 3.0 da.
- unsichere Zukunft, der Verkauf klappt wohl nicht so wie geplant.
- Die VCL ist angegraut und dem Net-Framework um Längen technologisch unterlegen.
- Keine oder ungenügende Unicode-Unterstützung.
- Das bpl Konzept ist zu allen anderen Lösungen inclusive unterschiedlicher Borland Versionen, inkompatibel und störanfällig.
- Wenig Unterstützung für serverseitige Programmierung.
- kaum Unterstützung für alternative Franmeworks (Compactframework...)
- Das VCL Datenmodell ist etwas verkorkst.
- IDE schwerfällig und immer noch buggig.
- Toolproduzenten schwenken zunehmend auf Net um.
- Viele Lösungen, welche ich unter Delphi zugekauft habe, sind im Net Framework bereits enthalten.

Delphi/VCL und Net haben den gleichen Vater.
Dem Framework ist anzumerken, das Delphi Pate stand und aus den Fehlern der VCL
gelernt wurde.
Neben VS2005 - kostenpflichtig und Eclipse - kostenlos, sehe ich wenig Raum für eine weitere
(sündhaft teuere) IDE. Die müste dann schon um Größenordnungen besser sein.

Das einzige was im Moment noch für Delphi spricht ist die Verwendbarkeit von Altcode und
die Pflege von Win32 Altprojekten.

Wenn ihr unbedingt mit Pascal weiterarbeiten wollt, dann schaut euch doch mal Chrome von Remobjects an.
Das wäre übrigens auch für mich eine vorstellbare Lösung. Ein Delphicompiler, der sich in VC2005 integriert - Da würde ich sicherlich noch einmal in Delphi investieren.


Gruß Peter

[Jürgen Thomas]

Und noch eine Beruhigung für "Deine" Delphianer-Kollegen: Der Wechsel von Delphi zu C# ist völlig unproblematisch (ich habe ihn selbst vor kurzem vollzogen); es handelt sich nur um ein paar Schreibweisen: geschweifte Klammern statt begin/end, Angabe der Typen vor statt hinter der Variablen, void-Methoden statt der Unterscheidung zwischen Prozedur und Funktion u.ä.

Die wesentliche Änderung ist die Einarbeitung in die NET-Klassen; und die muss/sollte jeder mitmachen. (Und die Verpackung der VCL in NET ist natürlich nur eine Notlösung.)

Gruß Jürgen

[Matthias Schröder]

Wie ich diese Forum liebe. :oops:
@Elvis. Danke für die Infos. Da ich mit Oralce noch nichts am Hut hatte, musste ich erst einmal ein paar Dinge nachschlagen (OCI, InstantClient). :gruebel:
Was aber meinstest du mit "mehrere MB InstantClient vs CoreLabs Direct ?" So wie ich das verstanden habe würde ich OraDirect von CoreLabs mit einem InstantClient und OCI verwenden. Oder was bedeutet das vs in deiner Aussage. :gruebel:

@hanspeter: Danke dir. Endlich mal ein paar schlagkräftige Argumente. Hätte man in einem Delphi-Formum vielleicht gar nicht erwartet. :stupid: Werde ich mal so aufnehmen, und wohl auch kommunizieren. Chrome und Remobjects werde ich mir mal ansehen. Sind diese Delphicompiler .NET 2.0 kompatibel?
Viiiielen Dank und Gruß

@Jürgen: Danke, dass sollte sie beruhigen :wink: Ich war halt immer der Ansicht, dass die VCL.NET viel mächtiger ist als die WinForms unter .NET. Ich hatte ja mal ein Gespäch mit den Delphi Kollegen, da kamen wir auch auf die Contols zu sprechen. Es schien mir so, als würde es in der VCL ca. 2,5 Mio mal so viele Visual Controls geben als unter .NET. Ferner sollten diese auch leicht erweiterbar sein, wobei das ja bei .NET Conrols auch möglich ist.
Matthias

[Elvis]

Zitat:

Zitat von Matthias Schröder

Was aber meinstest du mit "mehrere MB InstantClient vs CoreLabs Direct ?" So wie ich das verstanden habe würde ich OraDirect von CoreLabs mit einem InstantClient und OCI verwenden. Oder was bedeutet das vs in deiner Aussage. :gruebel:

Wie du abwägen willst, ob du mehrere MB für den InstantClient akzeptieren willst, oder ob du den CoreLabs Provider kaufen und die Direct-Option nutzen willst, die keinerlei externe ClientLib benötigt. Dafür aber etwas langsamer ist.

Zitat:

Zitat von Matthias Schröder

Chrome und Remobjects werde ich mir mal ansehen. Sind diese Delphicompiler .NET 2.0 kompatibel?

Nein, Chrome ist nur sehr eingeschränkt kompatibel zu Delphi und das auch nur mit Legacy switches. "Reines" Chrome ist einfach zu ... anders. Wobei ich das was da anders ist eigentlich als sehr positiv empfinde. ;)

Zitat:

Ich war halt immer der Ansicht, dass die VCL.NET viel mächtiger ist als die WinForms unter .NET. Ich hatte ja mal ein Gespäch mit den Delphi Kollegen, da kamen wir auch auf die Contols zu sprechen.

Sorry, höre ich immer wieder. Und meistens haben sich diejenigen noch nicht mit Designer-Interaktion und Databinding (richtiges Databinding, nicht dieser DataSet Bulls**t ;) ) auseinandergesetzt.
Rein von der Architektur her ist SWF eine fantastische, extrem mächtige GUI-API, dummerweise ist sie so lahm als würde sie Swing den Rang ablaufen wollen. :wall:

Zitat:

Es schien mir so, als würde es in der VCL ca. 2,5 Mio mal so viele Visual Controls geben als unter .NET.

Nicht VCL und VCL.Net verwechseln. Kaum ein Anbieter für VCL Komponenten bietet VCL.Net Komponenten an, benutzen einfach zuwenige.

[hanspeter]

Zitat:

Sind diese Delphicompiler .NET 2.0 kompatibel?

Chrome ist nicht Net 2.0 kompatibel, Chrome ist NET 2.0.

Wird im VS2005 als Plugin installiert und fügt sich nahezu nahtlos ein.

Der Editor kann ein bischen weniger als der VS2005 Editor.
Die Sprache ist zu Delphi kombatibel, hat aber viele angegraute Delphi Zöpfe abgeschnitten.
Enthält eigentlich das, was ich mir seit Delphi 3 für den Compiler gewünscht hätte.

Beispiel:

case Dat of
'text1' :
'Text2' :
end;

Und das was Borland mit Kylix hat machen wollen, der Compiler wird regelmäßig gegen Mono (Linux)geprüft.

Das Problem ist nicht die Sprache, sondern das Framework VCL =! Winforms.
Wenn hier nicht sauber zwischen Oberfläche und Verarbeitung getrennt wurde, dann
kommt die Umstellung fast an ein Neuschreiben heran.

Diese flexiblen Plugin machen zumindest für mich den eigentlichen Vorteil von VS2005 aus.
Inzwischen gibt es ja fast jede Sprache (z.B. XML, PHP, Fortran, Cobol) ein Compiler-Plugin.
Der eigentliche Vorteil von Dot.Net ist jedoch , das ich auf allen unterstützten Plattformen mit der gleichen Umgebung rechnen kann. Compilerabhängige Laufzeitbibliotheken somit überflüssig werden.
Die Vorteile für eigene Projekte überwiegen, wenn man solche Dinge wie Versionskontrolle für dll, XCopy Installation, ausgefeiltere Rechtekontrolle u.s.w. berücksichtigt.


Gruß Peter

[Matthias Schröder]

Wieder ein Dankeschön für alle eingehenden Beiträge :thumb:

@Elvis: Nun hab ich das auch gerafft. Was genau ist eigentlich der InstantClient. Ist das ne Light Version eines Oracle Clients? Reizen würde mich das schon, so ganz ohne Client auszukommen. Die Frage ist nur, wie stark die Performanceeinbußen sind?

Zitat:

Und meistens haben sich diejenigen noch nicht mit Designer-Interaktion und Databinding (richtiges Databinding, nicht dieser DataSet Bulls**t :Wink: ) auseinandergesetzt.

Oh, da bin ich aber mal gespannt was du unter richtiges Databinding verstehst. :stupid:

Zitat:

Nicht VCL und VCL.Net verwechseln. Kaum ein Anbieter für VCL Komponenten bietet VCL.Net Komponenten an, benutzen einfach zuwenige.

Ups. Okay, also muss ich die WebForms schon mit VCL.NET vergleichen, logo. Und wie sind da die Machtverhältnisse? Ist die VCL.NET umfangreicher? Performanter?

@hanspeter:Coole Sache das mit den Plugins, kenne ich sonst nur von Eclipse. Werde ich mir auf jeden Fall mal anschauen.

[Phoenix]

Zitat:

Zitat von Matthias Schröder

Ist die VCL.NET umfangreicher? Performanter?

Gerade das Gegenteil ist der Fall:
Es gibt inzwischen mehr Anbieter für native Windows Forms Controls als für die VCL.NET.
Und da die VCL.NET des öfteren noch P/Invokes verwendet die ja bekanntermassen immer langsam sind die auch langsamer als reine .NET Komponenten.

[Matthias Schröder]

Zitat:

Und da die VCL.NET des öfteren noch P/Invokes verwendet die ja bekanntermassen immer langsam sind die auch langsamer als reine .NET Komponenten.

Macht .NET denn was anderes? Sind das nicht auch P/Invokes, die dort verwendet werden? Jedenfalls ist mir mal sowas zu Ohren gekommen.

[Phoenix]

Jain. Bei Microsoft ist das 'It Just Works(TM)' - Magic. Zwar gibts bei Windows Forms am Schluss auch API Calls um die Fenster zu zeichnen, aber da der wo die Calls hier macht direkt von MS kommt muss der nicht durch die Framework-Security durch und deswegen geht das da ziemlich zügig vonstatten. Alles andere was P/Invoke macht muss da durch und wird ausgebremst.

[mkinzler]

Zitat:

Macht .NET denn was anderes? Sind das nicht auch P/Invokes, die dort verwendet werden? Jedenfalls ist mir mal sowas zu Ohren gekommen.

Was 2 (Microsoft und Borland) das Gleiche tun ist das noch lang nicht das Selbe! Da .Net durch die CAS im Gegensatz zu VCL.Net nicht ausgebremst wird

[Matthias Schröder]

Ja vielen Dank nochmal. Ich glaube mir konnte hier geholfen werden :hello:
FAZIT:
Ich werde dann wohl auf C# zurückgreifen und hier dann den Ora Direct.NET Data Provider verwenden. Den Umstieg auf C# mögen mir meine beiden Kollegen verzeihen. Scheint aber ja nur zu ihrem Besten zu sein.
Falls noch Argumente für oder gegen das eine oder andere sprechen, posted ruhig weiter. Ich bin für jede Info dankbar.

Gruß Matthias