1.2 .NET unter die Lupe genommen

Die Evolution der Softwaretechnik hat unter Windows zu einer immer größeren Funktionssammlung geführt, die immer komplexere Kommunikationsschnittstellen erforderte. Die Funktionssammlung ist in C geschrieben und heißt WinAPI-32, die Schnittstelle ist zentral in der Registrierungsdatenbank gespeichert und hat den Namen COM. Microsoft versuchte beides in objektorientierter Form zusammenzuführen und veröffentlichte die Funktionssammlung unter dem Namen Microsoft Foundation Classes (MFC) für Visual C++ und erweiterte die Schnittstelle auf COM+. Dieses historisch gewachsene »Stückwerk« machte die professionelle Benutzung für Softwareentwickler recht schwer.

Glücklicherweise hat Microsoft mit .NET einen Schnitt gemacht. .NET ist eine Plattform, nicht nur eine Programmiersprache. Damit tritt die Wahl der Sprache in den Hintergrund. Verstärkt wird dies durch die Plattformunabhängigkeit von .NET. Aus meiner Sicht als Softwareentwickler ist aber das grundlegend neue Design am wichtigsten, das nicht jede Menge Altlasten mit sich herumschleppt. Java hat das Design maßgeblich beeinflusst.

1.2.1 .NET – Ein paar allgemeine Eigenschaften

Wir wollen uns nun ansehen, welche wesentlichen programmiertechnischen Neuerungen .NET mit sich bringt. Wenn Sie Java bereits kennen, wird Ihnen einiges bekannt vorkommen. Aber .NET ist mehr als Java.

• Objektorientierung .NET ist 100 %ig objektbasiert. Es gibt nichts außerhalb von Objekten, auch Zahlen nicht. Betriebssystemaufrufe werden in Klassen und Objekten gekapselt.

• WinAPI-32-Ersatz Langfristig soll das .NET Framework die Win32-API ersetzen. Damit verwischen sich auch die charakteristischen Merkmale der verschiedenen Sprachen: Alle nutzen dieselben Bibliotheken – identische Funktionalität und Effizienz.

• Plattformunabhängigkeit .NET-Anwendungen werden in eine Zwischensprache übersetzt und erst zur Laufzeit in Maschinencode übersetzt. Die Spezifikation der Laufzeitumgebung (Common Language Runtime – CLR) ist ein offener ECMA-Standard, der vom Mono-Projekt für eine Implementation von .NET unter Linux genutzt wird.

• Sprachunabhängigkeit Alle Sprachen in .NET basieren auf demselben Typsystem, daher kann der Code einer Sprache von einer anderen genutzt werden. Auch interlinguale Vererbung ist erlaubt.

• Speicherverwaltung Ein Garbage Collector genannter Prozess kümmert sich automatisch um die Freigabe nicht mehr benötigten Speichers.

• Weitergabe Ein .NET-Programm kann, muss aber nicht installiert werden (Installationsassistent oder ClickOnce). Oft reicht ein einfacher Kopiervorgang.

1.2.2 Das Sprachenkonzept

Wenn wir eine .NET-basierte Anwendung entwickeln, ähnelt der Ablauf der Kompilierung bis zum Start der Laufzeitumgebung dem Ablauf unter Java. Zuerst wird ein Zwischencode erzeugt, der CPU-unabhängig ist. Die Dateiendung lautet .exe, wenn wir eine eigenstartfähige Anwendung entwickelt haben. Allerdings ist diese Datei nicht ohne Weiteres lauffähig, sie benötigt zur Laufzeit einen »Endcompiler«, der den Zwischencode in nativen, plattformspezifischen Code übersetzt. Der Zwischencode einer .NET-Anwendung wird als MSIL-Code (Microsoft Intermediate Language) oder nur kurz als IL bezeichnet, und der Endcompiler wird JIT-Compiler (Just-In-Time) oder auch nur kurz JITter genannt.

Abbildung 1.1 Der Ablauf der Entwicklung eines .NET-Programms bis zur Laufzeit

1.2.3 Common Language Specification (CLS)

Eine Java-Anwendung ist mit der Programmiersprache Java entwickelt worden, eine .NET-Anwendung hingegen ist nicht sprachgebunden. Ihre Visual-Basic-Programme können direkt C#-Routinen aufrufen, und umgekehrt können C#-Entwickler Ihre Arbeit nahtlos nutzen. Ausschlaggebend ist am Ende des Kompiliervorgangs nur ein kompatibler IL-Code.

Um sprachunabhängigen Code erzeugen zu können, legt die Common Language Specification (CLS) die Datentypen fest, nicht die .NET-Sprache. Die CLS ist ein offener Standard. Das animierte viele Softwareunternehmen, lange vor der offiziellen Einführung von .NET andere Sprachen (beispielsweise Delphi, Eiffel und Cobol) auf .NET zu portieren. Microsoft bietet mit C#, J#, C++ und VB .NET im Visual Studio vier verschiedene Sprachen an.

Abbildung 1.2 Die Common Language Specification als Basis der Sprachunabhängigkeit

Die Entscheidung, eine Anwendung auf der Grundlage von .NET zu entwickeln, ist keine Entscheidung für oder gegen eine Sprache – sie ist eine konzeptionelle Festlegung. Es gibt unter .NET keine bevorzugte Programmiersprache.

1.2.4 Common Type System (CTS)

Jede Entwicklungsumgebung beschreibt als eines ihrer wichtigsten Merkmale ein Typsystem, in dem die Datentypen und deren Erweiterungsmöglichkeiten spezifiziert werden. Außerdem regelt es den Zugriff auf die Datentypen. In der NET-Plattform heißt das Typsystem Common Type System (CTS).

Während die Definition des Typsystems bei herkömmlichen Sprachen Bestandteil der Sprache selbst ist, wandert das .NET-Typsystem in die Laufzeitumgebung. Kommunizieren zwei Komponenten miteinander, die in unterschiedlichen Sprachen entwickelt worden sind, sind keinerlei Typkonvertierungen mehr notwendig, da sie auf demselben Typsystem aufsetzen.

Alle Werte im CTS sind Objekte eines bestimmten Typs. Wenn nötig, findet beim Zugriff eine automatische Umwandlung in ein Objekt statt, zum Beispiel für Zahlen. Typen können ihrerseits Mitglieder enthalten, unter anderem auch Typen. Das CTS regelt auch die Berechtigungen, von wo aus auf einen Typ oder dessen Mitglieder zugegriffen werden kann. Zum Beispiel kann ein Zugriff nur innerhalb derselben Bibliothek erlaubt sein.

1.2.5 Common Language Runtime (CLR)

Die Common Language Runtime (CLR) ist die Umgebung, in der die .NET-Anwendungen ausgeführt werden – sie ist gewissermaßen die allen gemeinsame Laufzeitschicht. Die CLR ist ein Verwalter (englisch manager). Daher wird der darin ablaufende Code auch als verwalteter Code bezeichnet (englisch managed Code). Umgekehrt kann mit dem Visual Studio auch unverwalteter Code geschrieben werden. In unverwaltetem oder unmanaged Code sind beispielsweise Treiberprogramme geschrieben, die direkt auf die Hardware zugreifen und deshalb plattformabhängig sind.

Die CLR besteht aus zahlreichen Diensten und ist das Bindeglied zwischen dem verwalteten IL-Code und der Hardware. Zu diesen Diensten gehören:

• Class Loader zum Laden von Klassen in die Laufzeitumgebung

• Type Checker zur Unterbindung unzulässiger Typkonvertierungen

• JITter zur Übersetzung des MSIL-Codes zur Laufzeit in nativen Code

• Exception Manager zur Ausnahmebehandlung

• Garbage Collector zur automatischen Speicherbereinigung unbenutzter Objekte

• Code Manager zur Verwaltung der Codeausführung

• Security Engine zur Kontrolle, ob der User berechtigt ist, den Code auszuführen

• Debug Machine zum Debuggen der Anwendung

• Thread Service zur Unterstützung multithreading-fähiger Anwendungen

• COM Marshaller zur Kommunikation mit COM-Komponenten

1.2.6 .NET-Klassenbibliothek

Die .NET-Klassen stehen nicht zusammenhangslos im Raum, wie beispielsweise die Funktionen der WinAPI-32, sondern stehen ausnahmslos in einer engen Beziehung zueinander, der .NET-Klassenhierarchie. Eine Klassenhierarchie können Sie sich wie einen Familienstammbaum vorstellen: Letztendlich haben alle den gleichen Stammvater. Diese Wurzel der Hierarchie ist in .NET die Klasse Object. Jede andere Klasse des .NET Frameworks ist darauf zurückzuführen und erbt deren Möglichkeiten. Außerdem kann es weitere Nachfolger geben, die sowohl die Charakteristika der Klasse Object erben als auch die ihrer direkten Vorgängerklasse. Auf diese Weise bildet sich eine mehr oder weniger ausgeprägte Baumstruktur. Jede Bibliothek stellt einen Teil dieses Baumes dar.

Ich habe 20.177 Datentypen in der .NET-Klassenbibliothek gezählt. Ein kurzer Überblick ist damit fast unmöglich. Verschärft wird dies dadurch, dass jeder Datentyp noch mehrere Mitglieder haben kann.

1.2.7 Das .NET Framework

Ein Framework ist ein Gerüst, mit dem Anwendungen entwickelt, kompiliert und ausgeführt werden. Es besteht aus vier Teilen: aus CLS, CTS, CTR und der Klassenbibliothek. Je nach Installationsumfang sind in der Klassenbibliothek auch ADO.NET und ASP.NET enthalten.

1.2.8 Das Konzept der Namensräume

Genauso, wie Sie Dateien auf Ihrer Festplatte in Verzeichnisstrukturen organisieren, so sind auch die Datentypen der .NET-Bibliotheken in »Namensverzeichnissen« gegliedert. Sie werden Namensräume (englisch Namespaces) genannt. Analog zu einem Dateipfad (Verzeichnis plus Datei) ist ein Datentyp nur dann eindeutig benannt, wenn sein Namensraum mit angegeben wird. Ohne diese Strukturierung hätten Sie über 20.000 Typen zu benennen – viel Vergnügen.

Verwechseln Sie nicht die Klassenhierarchie mit der Hierarchie der Namensräume. Eine Klassenhierarchie wird durch die Definition der Klasse im Programmcode festgelegt und hat Auswirkungen auf die Fähigkeiten einer Klasse, bestimmte Operationen ausführen zu können, während die Zuordnung zu einem Namensraum keine Konsequenzen für die Fähigkeiten eines Objekts einer Klasse hat. Es ist sinnvoll, aber nicht zwingend, eine Korrespondenz der Hierarchien von Namensräumen und Datentypen zu schaffen.

Anders als bei der Klassenhierarchie hat die Namensraumhierarchie mehrere Wurzeln. Die wichtigste heißt System und enthält die fundamentalen Datentypen in .NET. Die folgende Tabelle zeigt exemplarisch ein paar Namensräume.

Ich habe 629 Namensräume in .NET gezählt; die Tabelle ist also nur ein winziger Ausschnitt. Wenn Sie eine Funktionalität suchen, lassen Sie sich von den Namensraumstrukturen leiten. In diesem Buch werde ich mich auf Namensräume und Klassen beschränken, die in praktisch jeder Anwendung vorkommen.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.