Windows Developer

Expertencheck .NET Core - Teil 2

Expertencheck: Blazor in .NET Core 3.0 und der Weg zu .NET 5
Keine Kommentare

Die Version 3 von .NET Core ist erschienen. Wir haben uns mit Thomas Claudius Huber, Dr. Holger Schwichtenberg, Jens Lorek und Sebastian Gingter, allesamt .NET-Experten und Sprecher auf der aktuell stattfindenden BASTA!-Konferenz, über die neue Version und die weitere Entwicklung hin zu .NET 5.0 unterhalten. 

Im zweiten Teil unseres großen Expertenchecks geht es um die Integration von Blazor in .NET Core 3.0. Was ist damit jetzt schon möglich, wohin geht die Reise? Außerdem kommentieren die Experten die Entscheidung Microsofts, .NET Core zukünftig in .NET 5.0 aufgehen zu lassen.

Lesen Sie auch Teil 1 des Expertenchecks: Was sind die Highlights in .NET Core 3.0? Für wen lohnt sich ein Update?

Blazor in .NET Core 3.0

Entwickler: Blazor ist Teil von .NET Core 3.0. Dabei unterscheidet Microsoft zwischen “Server-side Blazor” und „Client-side Blazor.“ Was ist damit möglich?

Meiner Meinung nach ist Blazor ein sehr vielversprechendes Framework zum Entwickeln von Web-Applikationen.

Thomas Claudius Huber: Mit beiden Blazor-Varianten lassen sich Komponenten-basierte Web-Applikationen entwickeln. Das Besondere an Blazor ist, dass eben nicht JavaScript oder TypeScript zum Einsatz kommt, sondern C#. Das UI selbst wird mit HTML/CSS entwickelt und die Logik in C# implementiert. Vom Programmiermodell sind beide Blazor-Variante, Server-side und Client-side, weitestgehend identisch. Bei server-side Blazor findet die Logik auf dem Server statt. Im Client läuft pures HTML/CSS/JavaScript. Die Kommunikation mit dem Server findet dabei via SignalR statt, was für den Entwickler automatisch im Hintergrund geschieht.

Die Experten

Thomas Claudius Huber ist Microsoft MVP im Bereich Windows Development und Senior Principal Consultant und Partner der Trivadis AG. Als Trainer, Berater und Entwickler ist er in den Bereichen C#, TypeScript, WPF, UWP, Angular und Azure unterwegs. Seine persönliche Webseite finden Sie unter www.thomasclaudiushuber.com.

Dr. Holger Schwichtenberg (alias „Dotnet-Doktor“) ist Leiter des renommierten .NET-Expertennetzwerks www.IT-Visions.de, das zahlreiche Unternehmen in Europa durch Beratung, Schulung, Coaching und Support unterstützt. Zudem ist er Entwicklungsleiter beim Softwaredienstleister 5Minds IT-Solutions GmbH & Co. KG (http://www.5Minds.de).  @DOTNETDOKTOR.

Jens Lorek ist Senior Software Engineer bei der Accso – Accelerated Solutions GmbH. Durch mehr als zehn Jahre Erfahrung im Bereich der .NET-Entwicklung hat er schon einige Trends kommen und gehen sehen. Deswegen ist er ein ziemlicher Fuchs, wenn es in der Projektarbeit darum geht, auf die richtigen Technologien zu setzen.

Sebastian Gingter blickt auf über fünfzehn Jahre Erfahrung als professioneller Softwareentwickler zurück. Im Zuge seiner Arbeit bei der Thinktecture AG liegt sein Fokus auf modernen (Web-)Technologien sowohl auf dem Client mit Type- und JavaScript, als auch auf dem Server mit JavaScript unter Node.js oder C# mit klassischem ASP.NET und .NET Core. Seinen Blog findet man unter https://gingter.org. Twitter: @PhoenixHawk

Client-side Blazor ist die deutlich interessantere Variante, da sich damit eine echte Single-Page-Application (SPA) entwickeln lässt. „Echt“ heißt dabei, dass der C#-Code im Client mit Hilfe von WebAssembly abläuft. Moderne Browser unterstützen WebAssembly bereits, womit Blazor eine ernstzunehmende Alternative zu Angular & Co. darstellt. Beim Client-side Blazor mit WebAssembly ist das Interessante, dass eine Mono-Laufzeitumgebung im Browser hochgefahren wird, welche dann ganz gewöhnliche .NET-Standard-2.0-Klassenbibliotheken laden kann. Das Ganze riecht von der Funktionsweise her ein bisschen nach Silverlight, nur mit dem großen Unterschied, dass kein Plug-in zum Einsatz kommt, sondern lediglich vom Browser nativ unterstützte Web-Standards genutzt werden. Meiner Meinung nach ist Blazor ein sehr vielversprechendes Framework zum Entwickeln von Web-Applikationen.

Dr. Holger Schwichtenberg: Achtung: Nur Server Side Blazor erscheint! Mit Server Side Blazor lassen sich nun Webanwendungen entwickeln, die sich anfühlen wie eine Single-Page-Web-Application. Allerdings ohne Offline-Fähigkeit und mit begrenzter Skalierbarkeit. Das „echte“ Blazor (C# auf Basis von WebAssembly im Browser) erscheint erst später.

Jens Lorek: Das Aufkommen von Server-side Blazor zeigt, wie gut das Design von Bazor im Kern ist. Wir können unseren Client-side-Code entweder auf dem Client oder dem Server ausführen, und alles was wir dafür ändern müssen, ist eine Zeile im Startup-Code. Das finde ich sehr beeindruckend. Und auch wenn sich zunächst die Client-side-Variante verbreitet hat, so ist die Server-side-Variante für mich wesentlich spannender. Der State ist im Server und nicht im Client. Da jeglicher Code nun auf dem Server ausgeführt wird, haben wir Out-of-the-Box eine geteilte Datenhaltung. So entwickelt man echtzeitfähige Multiuser-Anwendungen, quasi ohne es zu merken.

Ähnliche Konzepte gibt es bereits in anderen Sprachen, wie zum Beispiel in Elixir. Dort wurde vor kurzem mit LiveView ebenfalls ein sehr performantes Framework zur Server-side-Verarbeitung vorgestellt. Daten und Events werden dazu über eine WebSocket-Verbindung an den Server geschickt und die daraus resultierenden Änderungen am DOM des Clients in leichtgewichtige Deltas verpackt. Das Ganze ist dann natürlich eher weniger kompatibel mit anderen Konzepten wie PWAs, welche sich meiner Meinung nach in der breiten Masse aber auch erst noch behaupten müssen.

Mehr zum Thema: Microsoft Blazor: Razor Syntax und C# im Browser

Sebastian Gingter: Server-side Blazor ist ein Hybrid zwischen einerseits dem ganz klassischen Webseiten-Modell, bei dem das gesamte HTML auf dem Server gerendert und zum Browser gesendet wird, jede Benutzereingabe als Formular zum Server geschickt wird und dieser damit eine neue Seite erzeugt hat, und andererseits dem SPA-(Single-Page-Application)-Modell, bei dem eine Anwendung im Web-Browser lebt und dort ihr HTML erzeugt und für den Datenaustausch APIs auf einem Server aufruft. Interessanterweise verschiebt Server-side Blazor nun den Code, der in einer SPA im Browser läuft, auch auf den Server. Die Anwendung und der komplette Zustand jeder geöffneten Instanz der Anwendung lebt auf dem Server. Server-side Blazor setzt dazu auf eine permanent offene WebSocket-Verbindung (bzw. das auf WebSockets aufsetzende SignalR-Protokoll) zwischen dem Browser und dem Server, um sämtliche User-Eingaben an den Server zu senden, dort die HTML-Änderungen zu berechnen und diese wieder via WebSockets an den Browser zu senden, der diese dann anzeigt. Das Konzept ähnelt dem eines klassischen Thin-Clients (Terminal), der nur für die Ein- und Ausgabe von Daten zuständig ist, während sämtliche Berechnungen auf dem Mainframe geschehen.

Habe ich nun also ein Umgebung, bei der ich für alle Browser eine permanente, stabile und schnelle Verbindung zum Webserver sicherstellen kann, und habe ich genug Serverkapazitäten (sowohl CPU als auch Arbeitsspeicher), um das Zustands-Management für alle Clients, die aktuell verbunden sind, zu verwalten, dann kann mir Server-side Blazor dabei helfen, die Last von eher schwachbrüstigen „Thin clients“, auf denen nur der Browser läuft und nicht viel arbeiten muss, wegzunehmen. Ich persönlich halte Server-side Blazor aufgrund der zwingenden Einschränkung auf eine permanente stabile Server-Verbindung für moderne Businessanwendung aktuell nur für begrenzt sinnvoll. Zur Entwicklungszeit kann dies allerdings schon eine Möglichkeit bieten, sich auf Client-side-Blazor-Anwendungen vorzubereiten.

Später, hoffentlich schon mit .NET 5, soll es dann möglich sein, die Client-side Blazor-Anwendung unmittelbar in direkt ausführbares WebAssembly zu übersetzen.

Client-side Blazor wiederum entspricht dem aktuellen SPA-Modell, bei dem ich meine in HTML, CSS und eben C# geschriebene und dann in WebAssembly kompilierte Anwendung vollständig im Browser laufen lassen kann, und diese wie klassische JavaScript-basierte SPAs nur bei Bedarf mit einem Server kommunizieren muss. Hiermit kann man daher auch vollständig offline-fähige PWAs (Progressive Web Apps) bauen, die sich z.B. auf Mobilgeräten wie eine normale App installieren lassen. Stand heute ist das Ausführungsmodell leider noch etwas ungelenk: Aktuell wird die Mono Runtime zu WebAssembly-Code kompiliert und dieser WebAssembly-Zwischencode dann im Browser JIT-(Just-in-Time)-kompiliert und ausgeführt. Diese Mono Runtime lädt dann den IL (Intermediate Language)-Code unserer Webanwendung und JIT-kompiliert diesen zur Ausführung in der WebAssembly-Runtime des Browsers. Dann erst läuft unsere Anwendung.

Später, hoffentlich schon mit .NET 5, soll es dann möglich sein, die Client-side Blazor-Anwendung unmittelbar in direkt ausführbares WebAssembly zu übersetzen, so dass der aufwändige und aktuell noch sehr ineffiziente Zwischenschritt mit der Mono Runtime auf der WebAssembly Runtime (also im Prinzip eine Ausführungs-VM auf einer Ausführungs-VM) wegfällt. Wenn Blazor bis dahin auch alle notwendigen Features eines modernen SPA-Frameworks wie Angular, React oder Vue bereitstellt, beispielsweise ein echtes Web-Komponentenmodell, das auch CSS beinhaltet, hierarchische sowie relative Routen ermöglicht, Feature-Module (z.B. Anwendungsteile via NuGet-Paketen) und Lazy-Loading von Anwendungsteilen (komplexere Teile nur dann laden, wenn sie auch wirklich benötigt werden), dann könnte sich Blazor zu einer Technologie mausern, mit der man produktiv Browser-basierte Businessanwendungen in HTML, CSS und C# erstellen kann. Bis dahin ist man meiner Meinung nach allerdings noch mit den aktuellen SPA-Frameworks und TypeScript bzw. JavaScript besser bedient, wenn man wirklich produktiv Web-Anwendungen schreiben möchte.

Kostenlos: Azure-DevOps-Spickzettel

Jetzt herunterladen und mit wenigen Befehlen das Kommando über Azure DevOps übernehmen!

Download for free

Aus .NET Core wird NET 5.0

Entwickler: Das Projekt .NET Core wird ja bald wieder verschwinden: .NET Framework, .NET Core und Mono sollen künftig in.NET 5.0 aufgehen. Was bedeutet das konkret für Anwendungsentwickler?

.NET Core ist die Zukunft, und es lohnt sich, bereits heute damit zu starten.

Thomas Claudius Huber: Der Name .NET Core wird vielleicht von der Bildfläche verschwinden, und wir sprechen nur noch von .NET 5.0. Doch tatsächlich ist .NET 5.0 die nächste Version von .NET Core. Somit ist .NET Core die Zukunft, und es lohnt sich, wenn möglich, bereits heute damit zu starten.

Dr. Holger Schwichtenberg: Da verschwindet ja nur der Namensbestandteil „Core“. NET 5.0 wird der direkte Nachfolger von .NET Core 3.0/3.1 sein. Wichtiger ist, dass das klassische .NET Framework nun wirklich nicht mehr weiterentwickelt wird und man die Migration bestehender Anwendungen erwägen muss.

Jens Lorek: Bis es soweit ist, dauert es ja noch über ein Jahr – der geplante Release-Termin ist im November 2020. Bis es also akut wird, kann man sich meiner Meinung nach etwas zurücklehnen und die Entwicklung beobachten. Aber generell finde ich es sehr begrüßenswert, eine gemeinsame Runtime zu schaffen, wobei die direkten Vorteile davon womöglich nicht für jeden relevant sind.

Ich erinnere mich in dem Kontext auch an die Zeiten von Silverlight. Dort hatte sich das Framework in einzelnen Bereichen wie zum Beispiel der Netzwerk-Kommunikation immer ein wenig vom vollen .NET Framework unterschieden. Für Multi Platform Libraries ist man daher nicht um unschöne und schlecht wartbare „#IF SILVERLIGHT“-Konstrukte herumgekommen. Dies ist im Bereich der Android- und iOS-Entwicklung immer noch der Fall. Ich bin gespannt, was .NET 5.0 abseits davon für weitere Vorteile bringen wird.

Lesen Sie auch: C# 8 – die neuen Features im Überblick

Sebastian Gingter: Verschwinden klingt sehrt hart. Die Runtime des alten .NET Framework wird in .NET 5 durch die CoreCLR ersetzt, und Mono bleibt uns ja weiterhin mindestens für Full-AOT-Projekte erhalten: Xamarin und Unity auf iOS / WatchOS / iPadOS benötigen Mono AOT weiterhin genauso wie Unity auf bestimmten Konsolen (PS4, Nintendo Switch). Und auch Client-side Blazor benötigt dies für die Kompilierung nach WebAssembly. Offenbar können die Arbeiten, die hier für Mono AOT geleistet wurden, noch nicht so schnell für die CoreCLR nutzbar gemacht werden, daher werden wir wohl noch eine Weile mit zwei verschiedenen Implementierungen der Laufzeitumgebung leben müssen.

Mit .NET 5 bekommt man allerdings einen ganzen Batzen neuer Möglichkeiten. Eine sehr wichtige davon ist es, sich vom Windows-Release-Zyklus lösen zu können. Oftmals hat man Anwendungen nicht auf eine neuere .NET-Framework-Version aktualisieren können, weil diese erst ab einer bestimmten Windows(-Server)-Version verfügbar war, die aber nicht vorausgesetzt werden kann.

Mit .NET 5 bekommt man einen ganzen Batzen neuer Möglichkeiten.

.NET 5 kann als Teil der Anwendung mit ausgeliefert werden, und somit ist man unabhängig von vorinstallierten Versionen des .NET Frameworks. Viele von den neuen Features, die dann mit .NET 5 zur Verfügung stehen, wird man allerdings erst langsam mit der Zeit bewusst einbauen müssen: Nur weil wir auf einmal ein sehr modernes, flexibles und leichtgewichtiges Konfigurationsmodell zur Verfügung haben, baut sich unser Code nicht automagisch von System.ConfigurationManager um. Genauso sind auch das strukturierte Logging und die nun Framework-eigene Dependency Injection Dinge, die ich als Entwickler in einer Anwendung nicht mehr missen möchte, weil sie mich so viel produktiver machen und mir viel mehr Kontrolle über das System geben. Aber man kann nicht erwarten, dass sich so etwas sofort und problemlos in eine jahrelang gewachsene Business-Anwendung integrieren lässt.

Wir haben also einige Dinge, die so bleiben werden, ein paar kleine Quick-Wins, die wir uns sofort zunutze machen können, und einen Geschenkkorb an neuen Möglichkeiten, die allerdings Planung, Integrationsarbeiten und selbstverständlich auch Tests erfordern. Nachdem sich .NET aber nach seinem Release vor 17 Jahren hauptsächlich „oben“ erneuert und modernisiert hat (beispielsweise WPF vor 12 Jahren, ASP.NET MVC vor 10 Jahren), ist es nun auch der komplette Unterbau, der auf den aktuellen Stand der Technik aktualisiert wird. Konkret bedeutet das für mich als .NET-Anwendungsentwickler also, dass ich mich in einem Umfeld betätige, das nicht stehen bleibt, sondern aktiv mit den aktuellen Entwicklungen unserer Zeit in der Softwareentwicklung Schritt hält. .NET ist gekommen, um zu bleiben.

Entwickler: Vielen Dank für diese spannenden Einsichten!

Im dritten Teil verraten uns die Experten, welche neuen Features  für .NET 5.0 ganz oben auf ihrer Wunschliste stehen.   

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -