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.
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 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.
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 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.

[hanspeter]

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.
@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).
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.

@hanspeter: Danke dir. Endlich mal ein paar schlagkräftige Argumente. Hätte man in einem Delphi-Formum vielleicht gar nicht erwartet. 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 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