Die 10 Hauptgründe, sich für .Net zu entscheiden

Microsoft verspricht mit .Net mehr Leistung und Programmierproduktivität und stellt gleichzeitig VB- und C++-Entwicklern ein noch nie dagewesenes Maß an Leistungs- und Rapid-Application-Design-Tools (RAD) zur Verfügung. Microsoft hat sogar die neue, speziell für die Arbeit mit dem .Net Framework konzipierte Programmiersprache C# eingeführt. Wenn auch .Net etliche angebliche Vorzüge hat, so sind IT-Manager verständlicherweise argwöhnisch. Da die Technologie neu ist, kann es schwierig sein kann, erfolgreiche und geschäftskritische Anwendungen, die in .Net geschrieben sind, ausfindig zu machen. Außerdem ist die Lernkurve für das .Net Framework nicht unwesentlich – manche der VB-Entwickler finden den Wechsel zu VB.Net komplizierter als alle früheren Wechsel auf neuere Versionen. Trotz dieses Kostenaufwands sprechen etliche stichfeste Argumente für den Wechsel:

1. Integration von Standards: XML, SOAP, und andere
In der Vergangenheit basierte die Microsoft-Architektur auf COM/DCOM, einem binären Standard, der prozessübergreifende Kommunikation ermöglichte. Wenn auch im Grunde nichts an diesem binären Standard auszusetzen gab, so war er außerhalb des Microsoft-Kosmos völlig bedeutungslos. Anders ausgedrückt: der Standard ermöglichte ohne weiteres keine Interoperabilität mit anderen Softwareplattformen.

Zusätzlich zurr fehlenden Interoperabilität mit COM stellte Datentransfer ein weiteres Problem dar. Während ADO den einfachen Datenzugriff ermöglichte, konnte die Übergabe dieser Daten von einer Stelle an eine andere problematisch werden. Beim ADO Recordset-Objekt handelte es sich um eine binäre Struktur, in der die Daten gespeichert waren, und auch dieses Binärformat war wiederum nicht relevant für Nicht-Microsoft-Plattformen.

.Net zielt darauf ab, diese Unzulänglichkeiten zu beseitigen, indem es bei Bedarf vollkommen Standard-basiert arbeiten kann. So werden z.B. Daten über Prozessgrenzen hinweg als XML übergeben, wobei diese Daten typischerweise einen Link zu einem XSD haben, so dass jeder Client die Daten ordnungsgemäß validieren kann.

SOAP ist ein auf XML basierendes Protokoll, das mit Webservices kommuniziert. Die Integration von SOAP ermöglicht jedem Client einen einfachen programmatischen Zugang, selbst bei Clients ohne Microsoft-Betriebssysteme.

2. Problemlose Bereitstellung
Das Thema Bereitstellung war schon immer eines der schwierigsten im COM-Alltag. COM bedient sich ausgiebig der Windows-Registry, um auf dem PC installierte Komponenten zu ermitteln. Das Konzept war gut: Es sollte immer nur eine einzige Instanz einer registrierten Komponente geben, und sämtliche Anwendungen sollten die gleiche Version benutzen. COM versprach, dass neue Versionen weiterhin abwärtskompatibel sein würden, doch war es den Entwicklern freigestellt, mit dieser Kompatibilität zu brechen, was sie manchmal dann auch taten.

.Net bedient sich eines anderen Ansatzes: Es greift überhaupt nicht auf die Registry zu. Stattdessen empfiehlt Microsoft, die Komponenten (in .Net als Assemblies bezeichnet) für jede Anwendung dezentralisiert zu laden. Auf diese Weise haben Änderungen an der Assembly X für die Anwendung ,Foo‘ keine Auswirkung auf die Anwendungsleiste der Assembly X. Das klingt nach den alten Zeiten, in denen mehrfache Kopien der gleichen DLL auf dem Computer herumschwirrten – und genauso ist es auch. Man hat auf diese Weise jedoch nicht mehr das Problem, dass Anwendungen auf das Verzeichnis WindowsSystem32 zugreifen.

Da sich .Net nicht der Registry bedient, kann die Bereitstellung zumeist ganz einfach durch Kopieren erfolgen. Es ist oftmals nicht erforderlich, Installationsdateien zu entwickeln. Zudem sperren Web-Anwendungen die Assemblies nicht, weshalb man eine Anwendung nicht zu beenden braucht, um die DLL zu aktualisieren.