(D)COM(+)(-Server), OLE, .NET - So viele Begriffe, so wenig Ahnung

[Phoenix]

Zitat von Medium:

Was .NET so nett macht ist, dass es zum einen verspricht, die IL für die jeweilige Plattform optimiert zu kompilieren, auf der man es gerade ausführen will, vor allem aber auch die weitestgehend objekt-orientierte Kapselung der WinAPI. Und dazu noch ein (bzw. zwei) hübsche GUI Frameworks. (Winforms und WPF.) Zudem ist im .NET Framework einiges an Helfern und Dingen, die man so im Programmieralltag braucht bereits als fertige Lib enthalten, wofür man in vielen anderen Umgebungen erst 3rd-Party Code suchen müsste. Es ist alles in allem wohl vor allem ein deutlich weicheres Kissen als die nackte WinAPI, und zwar "ab Werk".

Das trifft es ziemlich gut, lässt aber ein bisschen den 'Enterprise'-Teil von .NET aussen vor.
.NET bietet von Haus aus mit dem Entity Framework einen umfassenden OR-Mapper, hat für Kommunikation (insb. auch mit WebServices, aber auch alles andere) alles dabei (WCF), kann out of the Box aus verteilte Transaktionen, hat eine umfassende Konfigurations-API, umfassende Logging-API's, sehr gute Diagnostics-Schnittstellen um rauszufinden was alles in der Anwendung so abgeht etc.

Das macht .NET insbesondere für Backend-Infrastruktur geeignet (so wie auch Java gerne auf Servern eingesetzt wird). Und natürlich gibt es im Bereich Webentwicklung mit ASP.NET einen umfassenden Stack der mit Webforms und ASP.NET MVC auch zwei umfassende GUI-Konzepte mitbringt und mit Web API zur Bereitstellung von Webservices (neben WCF) auch gut gerüstet ist. Letztlich ist .NET an sich inzwischen so groß, das man als einziger Entwickler gar nicht mehr alles im Blick haben kann.

Gegenüber Java, wo gar nicht so viel direkt im JDK enthalten ist sondern man für einzelne Aufgaben immer wieder auf andere Produkte/Bibliotheken zurückgreifen muss, sehe ich hier aber einen riesen Vorteil: Die Java-Bibliotheken sind alle sehr... sagen wir mal heterogen. Die einen Funktionieren so, die anderen ganz anders. manche nutzen diesen DI-Container, andere einen anderen. Das macht das zusammenführen von verschiedenen Teillösungen zu einem Gesamtprodukt immer etwas schwierig, weil man viele Komponenten gar nicht so einfach verbinden kann ohne viel 'glue code' zu schreiben. Die Grundlegende Architektur von .NET und die ganzen Bibliotheken aus einer Hand sorgen dafür, das man sich nicht immer in neue Konzepte einarbeiten muss (das muss man einmal am anfang), aber dann funktionieren alle Bibliotheken irgendwie immer sehr ähnlich und lassen sich sehr schnell nutzen ohne viel 'verkleben' zu müssen. Das gefällt mir an dem ganzen .NET-Umfeld deutlich besser als bei Java.