C# vs. Delphi.NET II

[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