Kommentar: .NET Core 2.0 kann zwar mehr, aber es gibt immer noch gravierende Lücken
Bei der zweiten Hauptversion der Core-Produktfamilie fehlen wichtige Features, die Microsoft selbst teilweise hoch priorisiert hatte, meint Dotnet-Doktor Holger Schwichtenberg und schickt einen Appell an die Entwickler.
- Dr. Holger Schwichtenberg
In Version 1.x waren .NET Core, ASP.NET Core und Entity Framework nur dann eine gute Lösung, wenn man ein ganz neues Projekt begonnen hatte und außerdem genug Enthusiasmus mitbrachte, die vielen Lücken und Unzulänglichkeiten mit kreativen Ansätzen zu schließen. Nach dem alten Gedanken, dass eine Software sowieso erst in der zweiten Version etwas taugt, gilt es nun, die frische Version 2.0 neu zu bewerten.
19.000 neue APIs, aber vieles fehlt dennoch
Microsoft hat in .NET Core 2.0 rund 19.000 Programmierschnittstellen ergänzt, wobei hiermit nicht nur Klassen gemeint sind, sondern auch einzelne Klassenmitglieder. Enthalten sind neben den APIs, die in .NET Core 1.x noch nicht fertig waren, auch zahlreiche, die Microsoft in .NET Core 1.x in einem fehlgeleiteten Aufräumwahn absichtlich weggelassen hatte, wie System.DateTime.ToLongDateString().
Diese große Zahl darf nicht darüber hinwegtäuschen, dass .NET Core 2.0 nun keineswegs alle Klassen aus dem klassischen .NET Framework 4.7 anbietet. Microsoft zeigt immer die GUI-Anwendungsframeworks, wie Windows Forms, Windows Presentation Foundation (WPF) und ASP.NET, außerhalb der .NET Standard Library. Was in Microsofts Schaubild aber leider fehlt, ist die Darstellung der vielen Nicht-GUI-Klassen, die nicht im .NET-Standard enthalten sind und daher in .NET Core 2.0 weiterhin fehlen wie Caching (System.Runtime.Caching), Abspielen von Audiodateien (System.Media), Zugriff auf Betriebssystemressourcen (System.Management), Zugriff auf Konfigurationsdateien (System.Configuration), Dienste (System.ServiceProcess), Registry (Microsoft.Win32) und Workflows (System.Activities) sowie LINQ-to-SQL (System.Data.Linq) und das Hosten von WCF-Diensten (System.ServiceProcess).
(Bild: Microsoft)
Freilich sind einige dieser Konzepte sehr Windows-spezifisch und passen nicht zu einer Implementierung auf Linux oder macOS. Natürlich hat Microsoft in der .NET Core-Welt eigene Bibliotheken für Konfigurationsinformationen und Caching, und einige dieser Bibliotheken wie LINQ-to-SQL sind veraltet.
Weiterhin nur eng beschränktes Einsatzgebiet
In Summe bedeuten die vielen immer noch fehlenden Klassen in .NET Core aber: Mit der Aussage "One library to rule them all" hat Microsoft etwas zu hoch gegriffen. Bestehenden Quellcode von .NET Framework 4.x auf .NET Core 2.0 umzustellen, geht zwar einfacher als auf .NET Core 1.x, ist aber in vielen Fällen weiterhin ein immenser Aufwand, den man sich gut überlegen muss. Rechtfertigt der Performancegewinn von .NET Core die Migrationskosten? Muss meine Konsolen- oder Webanwendung wirklich auf einem Linux- oder macOS-Server laufen?
.NET Core 2.0 ist jedoch für neue Konsolen- und Webserveranwendungen eine Erwägung wert, insbesondere wegen der Web-APIs. Die Wahrscheinlichkeit, diese Abwägung positiv abzuschließen ist größer als bei .NET Core 1.x, zumal ja nun laut Microsoft 70% der Nuget.org-Pakete auch in .NET Core laufen. Wie bisher muss ein guter Softwarearchitekt aber im Vorfeld sehr sorgfältig prüfen, ob in der Core-Welt alle im konkreten Projekt benötigten Funktionen wirklich zur Verfügung stehen.
Kein GUI-Framework für den Desktop
.NET Core 2.0 ist weiterhin gar keine Lösung, wenn man eine Desktop-Anwendung erstellen oder migrieren will, denn es gibt hier kein GUI-Framework. Der im letzten Mai angekündigte XAML-Standard ist in .NET Core 2.0 nicht enthalten. Das für Ende 2017 geplante .NET Core 2.1 wird mit der Implementierung der XAML-Deserialisierung überhaupt erst den Grundstein legen für ein XAML-basiertes echtes Cross-Platform-GUI-Framework, das wir in mittlerer bis ferner Zukunft sehen werden. Solange programmieren wir unsere Cross-Plattform-Anwendungen weiterhin mit HTML 5, CSS und JavaScript/TypeScript.
Entity Framework Core bleibt eine Baustelle
Eine weitere große Baustelle in .NET Core bleibt der Datenzugriff mit Entity Framework Core. Hierzu hatte Microsoft schon Mitte 2016 kurz mit dem Erscheinen von Entity Framework Core 1.0 eine Roadmap vorgelegt, die zahlreiche "kritische" und weitere "hoch priorisierte" Features benannte, die in Entity Framework Core 1.0 fehlen. Wer nun – wie ich selbst – glaubte, dass Microsoft genau diese Funktionen als erstes implementieren würde, sieht sich in den Versionen 1.1 und 2.0 schwer getäuscht. Microsoft hat im letzten Jahr gerade einmal zwei der kritischen und nur ein einziges der Features mit hoher Priorität umgesetzt. Dabei hat das Unternehmen sogar eins der kritischen Features nur teilweise umgesetzt: Entity Framework Core 2.0 nimmt Gruppierungen auch weiterhin im RAM statt in der Datenbank vor – selbst wenn dadurch der Hauptspeicher mit Milliarden Datensätzen überschwemmt wird. Da auch weiterhin die Verwendung von SQL statt LINQ mit FromSql() nur mit Entitäts-Klassen funktioniert, sind alle verfügbaren Workarounds sehr hässlich.
Die Kommentare der Nutzer auf Github drücken das absolute Unverständnis klar aus, dass Microsoft so eine elementare Funktion auch ein Jahr nach dem Erscheinen der ersten Version immer noch nicht realisiert hat – stattdessen aber nun viele andere Punkte liefert, die vielleicht für manchen Fall ganz schön, aber eindeutig für die Mehrheit nicht so wichtig sind wie ein performantes GroupBy.
Nicht so flexibel wie geplant
Was aber am meisten daran frustriert, ist dass das Entwicklungsteam einen Pull-Request mit einer Implementierung von GroupBy nicht angenommen hat und immer wieder betont, dass die Umsetzung von GroupBy in dem bestehenden Quellcode nicht so einfach wäre. Dabei war Microsoft mit Entity Framework Core doch mit der Aussage angetreten, dass man den Quellcode des OR-Mappers in der Neuimplementierung einfacher und flexibler machen will, um agiler zu sein. Und jetzt ist diese Neuimplementierung so (schlecht?), dass man dort nicht einmal eine Gruppierungsfunktion einbauen kann? Das enttäuscht uns .NET-Entwickler doch wirklich sehr.
Daher mein Appell als .NET-Entwickler nach Redmond: Nehmt euch mal die eigene Prioritätenliste aus dem letzten Jahr zur Hand und fangt an, damit wenigstens bis Mitte 2018 die gravierenden Lücken geschlossen sind. Bitte beweist uns, dass in der Core-Welt eure Implementierungen wirklich besser sind als beim klassischen .NET Framework! (rme)
