Announcement

Collapse
No announcement yet.

VCL.NET und .NET (Delphi8)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • VCL.NET und .NET (Delphi8)

    Hi,

    ich habe heute (endlich) Delphi8 erhalten *freu*! Da ich von .NET nur im
    Grundsatz etwas gehört habe habe ich mir als erstes die Hilfe genommen und
    bin die grundsätzlichen Dinge durchgegangen. Dabei fällt es mir ein wenig
    schwer den genauen Unterschied zu VCL.NET und .NET festzumachen. Borland
    schreibt dazu in der Hilfe

    <PRE>
    -------- Schnipp --------------
    Es wäre ein Missverständnis, VCL.NET als ein untergeordnetes Element des
    .NET Framework zu betrachten, denn es handelt sich eher um eine parallele
    Funktionalität. VCL.NET und das .NET Framework sind auf funktioneller Ebene
    Äquivalente.
    -------------------------------
    </PRE>

    Weiterhin schreibt Borland das bei der VCL.NET alle (wie von den Vorgängern
    gewohnt) von TObject abgeleitet ist. Wenn ich jetzt aber von TObject mal den
    Code in den darunterliegenden Units (sagt man noch Units??) verfolge sieht
    es wie folgt aus:

    <PRE>
    ------- Schnipp ------------
    TObject = System.Object;
    -----------------------------
    </PRE>

    Also wenn ich mich nicht täusche bedeutet das doch das VCL.NET immer noch
    auf das .NET Framework basiert und somit beide Versionen äquivalent sind,
    oder nicht? Vielleicht habe ich da auch etwas falsch verstanden und jemand
    kann mich aufklären!?

    2te Frage: Mit was würdet ihr jetzt weiterprogrammieren(bestehende und neue
    Projekte)? Mit VCL.NET oder direkt mit .NET (Windows Forms-Anwendung)?

    3te Frage: Wenn ich in VCL.NET programmiere kann ich doch auch direkt auf
    die Funktion des .NET Frameworks zugreifen, oder nicht?

    Danke

    Gruß Rainer

  • #2
    Hallo,

    &gt;..das VCL.NET immer noch auf das .NET Framework basiert ..

    nein, die VCL.NET greift in der internen Implementierung direkt auf die "alten" über P/Invoke eingebundenen Win32-API-Funktionen zurück und ist daher <b>stellenweise</b> eine parallele Alternative zum Framework. Aus diesem Grund hat Borland durchaus Recht, wenn in der Hilfe der Satz "<i>Es wäre ein Missverständnis, VCL.NET als ein untergeordnetes Element des .NET Framework zu betrachten, denn es handelt sich eher um eine parallele Funktionalität</i>" auftaucht. Dieser Satz ist aufgrund der sich daraus ergebenden Nebenwirkungen aber nicht nur positiv zu sehen ;-)

    Man kann es auch so formulieren: <br>
    a) Interface-Abschnitt einer Unit = .NET <br>
    b) Implementation-Abschnitt einer Unit = Win32 + .NET

    &gt;TObject = System.Object;

    Dies ist notwendig, weil die CLR (Common Language Runtime) eine noch strengere Typprüfung an den Tag legt, als das bisher bei Delphi der Fall war. Somit muss sich auch Delphi beim eigenen <b>Objektmodell</b> dem neuen Chef unterordnen, aber die Implementierung der VCL-Methoden der einzelnen VCL-Klassen (Objekte) ist dann wieder in weiten Teilen "altes Win32". Außerdem hat Borland den VCL.NET-Klassen entsprechende <b>Class Helpers</b> zur Verfügung gestellt, die dafür sorgen, dass die "fremden" Methoden aus Delphi auch für System.Object-Nachfolger gelten. Aus diesem Grund sehen die VCL.NET-Objekte für uns noch genau so aus wie früher.

    &gt;Mit was würdet ihr jetzt weiterprogrammieren...

    Die VCL.NET dient nur für die mittelfristige Konvertierung von bestehenden Projekten. Borland hat auf offiziellen Kanälen gesagt, das man davon ausgeht, das nur 25...30% der Delphi-Kundschaft bereits bestehende Delphi-Projekte mit Delphi 8 weiterführen will. Der Rest (70...75%) fängt neue (Windows Forms-) Projekte an. Aus diesem Grund stehen die neuen Sachen wie zum Beispiel BDP.NET auch nur für Windows Forms (FCL) zur Verfügung, aber nicht für VCL.NET.

    &gt;Wenn ich in VCL.NET programmiere, kann ich doch auch <br>
    &gt;direkt auf die Funktion des .NET Frameworks zugreifen, oder nicht?

    Ja, fast alle Funktionen aus dem .NET Framework stehen zur Verfügung. Das "Grundübel" der VCL.NET bleibt aber bestehen: <br>
    a) deutlicher Performance-Einbruch aufgrund der ständigen P/Invoke-Aufrufe (ca. Faktor 20) <br>
    b) höhere Anforderungen an die Rechte (.NET Code Access Security) <br>
    c) eingeschränkte Exception Stack Trace (Nebenwirkung der Class Helpers) <br>
    d) eingeschränkte Brauchbarkeit für anderen Sprachen (die eventuell bestimmte Funktionen aus dieser Assembly "ausborgen" wollen)<br>
    e) u.s.w

    Comment


    • #3
      Hallo,

      danke für deine Antwort! HAt mir sehr weiter geholfen.

      Gruß Raine

      Comment

      Working...
      X