Menü
ASP.NET ist – wie der Name schon ein bisschen verrät – ein quelloffenes Framework für die Entwicklung von beliebigen Webanwendungen aus der .NET-Familie. Sprich einer dieser beliebten Fertigbaukästen, auf die eine Softwareentwicklerin zurückgreift, um sich möglichst vieler lästiger Programmier-Tätigkeiten zu entledigen und sofort an der eigentlichen Software-Lösung zu arbeiten – so ein Schummellieschen. ASP.NET steht dabei für Active Server Pages für .NET – nur so am Rande. Damit wird auf die Tatsache angespielt, dass .NET-Komponenten – der serverseitigen Technologie – HTML für den Browser generieren. Mit ASP.NET lassen sich aber nicht nur klassische serverseitige Webanwendungen entwickeln – die Dinger, bei denen für jede Oberflächenaktualisierung der Browser neu lädt – sondern auch eine ganze Reihe anderer Applikationen:
ASP.NET besitzt eine ganze Reihe an Eigenschaften, die für Entwickler, Administratoren aber auch für den Anwender von Bedeutung sind:
Alles in allem weist ASP.NET viele Eigenschaften auf, die es ideal für die effiziente Umsetzung eines professionellen Softwareentwicklungsprojektes in geschäftskritischen Unternehmensbereichen macht.
Wir haben es bereits angedeutet: In der Praxis gibt es nicht DIE eine ASP.NET-Anwendung. Vielmehr gibt es für jeden erdenklichen Anwendungsfall Sub-Frameworks in Form von Klassenbibliotheken.
Hierzu gehören:
Aber keine Sorge, diese Klassenbibliotheken sind bereits in ASP.NET enthalten. Es ist lediglich ein bisschen Konfiguration nötig, um diese auch zu aktivieren. Und das Beste: Sie müssen sich nicht für die eine oder andere entscheiden, denn alle Varianten können parallel in einem Projekt existieren. Aber was steckt hinter Razor Pages und Co. eigentlich genau? Das schauen wir uns in den nächsten Abschnitten genauer an.
Razor Pages bilden die einfachste Möglichkeit mit ASP.NET Webseiten zu entwickeln. Razor – zu Deutsch Rasierer – spielt auf die HTML-Templates mit C# (CSharp) an, die typisch für diese Technologie sind, – wenigstens ein Rasierer, den die Entwickler benutzen. Den Kern bilden, wie der Name schon sagt, Razor Pages. Darunter versteht man Komponenten, die aus einer HTML-Template-Datei (*.razor) und einer Code-Behind-Datei (*.razor.cs) bestehen. Der Code des HTML-Template bzw. die Razor-Datei dient zur Anzeige-Logik, also als View, z.B. für:
Der Code der Code-Behind-Datei kümmert sich um die serverseitige Geschäftslogik und dient allem, was unter der Haube stattfindet:
Eine gerechte Sache, wenn Sie mich fragen. Und so sieht eine Razor Page in echt aus:
public class IndexModel : PageModel
{
private readonly ILogger<IndexModel> _logger;
[BindProperty]
public string MyMessage { get; set; }
public IndexModel(ILogger<IndexModel> logger)
{
_logger = logger;
}
public void OnGet()
{
MyMessage= "Mein Softwareentwicklungs-Projekt mit PI :)";
}
}
Eine einfache Code-Behind-Datei mit einem sogenannten PageModel – die logische Präsentation Ihrer Seite.
@page
@model IndexModel
@{
ViewData["Title"] = "Meine neue Super-Seite";
}
<div class="text-center">
<h1 class="display-4">Welcome</h1>
<p>@MyMessage</p>
</div>
Das zugehörige HTML-Template, auch View genannt, mit typischer Razor-Syntax. Achten Sie mal darauf, was aus unserer “MyMessage”-Variable wurde!
Razor Pages kommen immer als Duo aus HTML-Template und Code-Behind daher. Was ist aber, wenn man dem Nutzer beim Aufruf einer URL je nach Parametrisierung der Anfrage unterschiedliche HTML-Templates präsentieren möchte? Denkbar wäre beispielsweise, dass eine Software-Lösung sich bei einem Administrator anders verhält als bei einem normalen Nutzer. Hier kommt das ASP.NET MVC ins Spiel. Das Kürzel steht dabei für:
In der Softwareentwicklung versteht man darunter ein typisches Muster:
Puh. Ganz schön viel Arbeit. Da waren unserer Razor Pages doch umgänglicher. Die Modularisierung einer Software-Lösung mit Model, View und Controller hat aber sein Gutes: Diese einzelnen Komponenten werden wesentlich besser getrennt. Und das hat bei größeren Projekten definitiv seine Vorteile:
ASP.NET MVC ist also genau das richtige für komplexere, serverseitige Webanwendungen oder für Migrationsprojekte von .NET Framework zu .NET bzw. vom klassischen ASP.NET zu ASP.NET Core – was wir heute einfach nur noch als ASP.NET bezeichnen.
Bisher sind wir immer davon ausgegangen, dass uns ASP.NET als Endnutzer mit mehr oder weniger hübschen Weboberflächen in Form von HTML beglückt. Diese Sichtweise ist allerdings etwas egoistisch, schließlich gibt es eine ganze Reihe von Akteuren im Inter- oder Intranet:
Alle haben eines gemeinsam: Sie sind vorrangig für andere Unternehmen bestimmt, nicht für den Ottonormalverbraucher. Für solche Szenarien kommen in der Regel normale Webanwendungen nicht in Frage. Ein mobiler Pflegedienst beispielsweise, möchte natürlich von seinen Klienten als eigenständiger rundum Dienstleister wahrgenommen werden. Da will man der netten alten Dame natürlich kein Orchester aus Webadressen und Logins aufdrängen.
Vielmehr werden alle notwendigen Dienste in Form von Web-APIs delegiert und unter einer einheitlichen Web-Maskerade vereinigt, ohne dass der Endkunde Wind davon bekommt.
Unsere Razor-Pages wären da nur Ballast, denn um die genannten Dienste umzusetzen, muss beim Aufruf einer URL mehr herauskommen als nur HTML, z.B.:
Und genau für diese Anwendungsfälle gibt es ASP.NET Web API. An dieser Stelle ist auch nicht mehr viel zur Technik hinzuzufügen. Denn die Softwareentwicklung erfolgt äquivalent zum Model View Controller-Pattern mit einem Controller. Nur dass dieser sinnvollerweise als “API-Controller” bezeichnet wird und nicht nur HTML aus Views generiert, sondern eben auch JSON und den ganzen anderen Daten-Zauber über den HTTP-Draht schicken kann.
Und so sieht das Schmuckstück dann im C#-Code aus:
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
namespace MeinWebanwendung.Controllers
{
[Route("api/[controller]")] // Achten Sie mal später auf die Adressleiste im Browser
[ApiController]
public class GreetingController : ControllerBase
{
[HttpGet]
public string Get()
{
return "Die PI Informatik wünscht frohe Digitalisierung :)";
}
}
}
Rein theoretisch kann man unsere ASP.NET Web API nun auch gleich im Browser ausprobieren.
Zugegeben: Ein Kunde würde sich von so einem Text kaum beeindrucken lassen. Aber kann man erstmal Text liefern, steht einem die Welt offen: Buchungsdaten, SEPA-Lastschriften, Stromverbräuche, Betriebsdaten und noch vieles mehr können nun ab sofort an andere Unternehmen ausgeliefert werden. Und es heißt ja nicht umsonst: Auch der längste Weg beginnt mit einem Schritt.
Wozu soll SignalR denn gut sein? Haben Sie sich schon mal Webanwendungen wie Google Docs oder Office 365 genau angesehen und ist Ihnen dabei was aufgefallen? Richtig! Kein lästiges Neuladen der Seite – fast so als würde man auf seinem Desktop arbeiten. Und falls es mehrere Bearbeiter gibt, erscheinen diese an der entsprechenden Bearbeitungsstelle im Dokument auch prompt als buntes Logo. Aber wie ist das möglich? Die Antwort darauf sind Websockets. Diese können Sie sich vereinfacht als eine Art Chat-Kanal vorstellen, in dem sich Server und Clients gegenseitig Nachrichten schicken können. Heißt, dass nicht nur Daten vom Browser zum Server wandern, sondern auch vom Server an den Client bzw. sogar auch an mehrere Clients (Broadcasting). Im Detail ist die Kommunikation mit Websockets aber nicht ganz unkompliziert und deshalb gibt’s wie so oft in der Softwareentwicklung eine zusätzliche Abstraktionsschicht, die lästige Standardaufgaben vom Entwickler fernhält:
Was ist also SignalR? SignalR ist ein Framework für die Softwareentwicklung von Webanwendungen auf Basis von Websockets.
Blazor ist die Krönung der Schöpfung in der ASP.NET-Welt. Und was steckt genau dahinter? Das ist tatsächlich ein bisschen konfus. Denn Blazor gibt es in zwei Spielarten:
Bei Blazor WASM wird … Trommelklang … .NET zu sogenannten WebAssembly-Code kompiliert und im Browser ausgeführt. Für den Softwareentwickler bleibt aber alles beim guten alten Razor Page-Konzept. Ein HTML-Template für die View und Code-behind für die Geschäftslogik, die jetzt allerdings via .NET und WebAssembly im Browser läuft. Razor für den Browser, wenn Sie so wollen. Deshalb auch der Name Blazor.
Beim Blazor Server sehen die Komponenten ebenfalls wie Razor Pages aus. Allerdings wird der .NET Code wieder auf dem Server ausgeführt. Im Gegensatz zu Razor Pages gibt es aber einen entscheidenden Unterschied: Alle Aktualisierungen in der UI erfolgen nicht durch Neuladen der Webseite, sondern durch Websockets, die mit Hilfe von SignalR im Hintergrund laufen. Im Ergebnis erhält man Kombination aus Razor Pages und SignalR und damit eine dynamische UI, die ohne Neuladen der Webseite auskommt – eben wie bei Google Docs oder Office 365.
Blazor eröffnet dadurch in der Softwareentwicklung ein ganzes Universum an Möglichkeiten. Da begnügen wir uns natürlich nicht mit einem kurzen Abschnitt.
Falls Ihnen das ebenfalls nicht ausreicht und Sie gerne mehr über die Vorteile und Einsatzmöglichkeiten von Blazor erfahren möchten, können Sie hier weiter schmökern.
Alles, was im Web geht, geht auch mit ASP.NET. Damit ist das Framework definitiv eine sichere Angelegenheit. Mit Razor Pages und Co. gelingt ein unkomplizierter und kostenschonender Einstieg. Und sollte man hier doch mal an die Grenzen von ASP.NET stoßen, stehen SignalR und Blazor schon hinterm Vorhang bereit. Dieser gigantische Wust an Möglichkeiten kann aber natürlich gerade am Anfang sehr viele Fragen aufwerfen und Verwirrung stiften.
Und sollten Sie mal das Gefühl haben, dass Ihr Projekt doch einen kleinen Schub von einem Softwareentwicklungs-Unternehmen braucht, wissen Sie ja, wo Sie uns finden.
