Das im Rahmen des .NET Framework 3.5 im November 2007 erschienene ASP.NET bietet nur eine enttäuschend kleine Anzahl von neuen Funktionen, wenn man es vergleicht mit ASP.NET 2.0 (November 2005) und den zwischenzeitlich im Januar 2007 publizierten ASP.NET-2.0-AJAX-Erweiterungen: Die AJAX-Erweiterungen gehören in ASP.NET 3.5 nun zum Standardlieferumfang des .NET Frameworks, AJAX kann jetzt auch mit WCF-Diensten kommunizieren und die neuen Steuerelemente ListView, DataPager und LinqDataSource bieten eine Vereinfachung für den Datenzugriff.
Von den Funktionen der im Jahr 2007 unter dem Titel «ASP.NET Futures» geführten Prototypen ist hingegen in ASP.NET 3.5 nichts zu sehen. Ein Teil dieser «Futures» ist auf längere Sicht nicht produktreif, einen anderen Teil wollen die Redmonder Mitte 2008 als Erweiterungspaket zu .NET 3.5 veröffentlichen. Auf der TechEd 2007 war zu hören, dass dieses umfangreiche Erweiterungspaket als Service Pack 1 eher «heimlich» eingeschleust werden soll, dabei würde der Umfang der Neuerungen mindestens ein «.NET 3.7» rechtfertigen.
Lange Zeit überliess Microsoft den Drittanbietern das ganze Themengebiet des Objekt-Relationalen-Mappings (ORM). In .NET 3.5 erblickte dann mit LINQ-to-SQL ein «einfacher» O/R-Mapper das Licht der Welt, der im Wesentlichen 1:1-Abbildungsszenarien und nur den Microsoft SQL Server unterstützt. Das ADO.NET Entity Framework (EF) ist ein weiterer ORM, der datenbankunabhängig ist und beliebige Abbildungen der Datenbankstrukturen auf Objektmodelle erlaubt. Die Vorgehensweise in EF ist ähnlich wie in LINQ-to-SQL, auch LINQ als Abfragesprache (siehe InfoWeek 20/2007, Seite 47) ist unter dem Titel LINQ-to-Entities enthalten. Dass es mit LINQ-to-SQL und dem EF dann zwei verschiedene ORM aus dem Hause Microsoft gibt, ist keine Strategie, sondern das Ergebnis fehlender Abstimmungsprozesse verschiedener Entwicklungsteams in Redmond.
Das EF ist sowohl in Windows- als auch Webanwendungen einsetzbar. In verteilten Anwendungen stehen die mit dem EF entwickelten Objektmodelle zunächst einmal nur auf dem Server zur Verfügung. Die ADO.NET Data Services bilden hier das Bindeglied zum Browser und anderen entfernten Clients. Ein Data Service ist ein Webservice, der ein Objektmodell über HTTP für entfernte Clients verfügbar macht.
Die Datenmenge definiert der Entwickler durch ein Modell im EF (mit Zugriff auf unterschiedliche relationale Datenbanken) oder jede andere Menge, die durch die Schnittstelle System.Linq.IQueryable abgefragt werden kann. Die Datenübertragung erfolgt in der Representational-State-Transfer-Semantik (REST), als Serialisierungsformate stehen JSON und ATOM zur Wahl (siehe Kasten «Datenabfragen mit den ADO.NET Data Services»). ADO.NET Data Services setzen technisch auf der mit .NET 3.0 eingeführten Windows Communication Foundation (WCF) auf.
ADO.NET Data Services vereinfachen die Übertragung von Daten zwischen Client und Server, nicht jedoch die Darstellung der Daten innerhalb von AJAX-Anwendungen. Bereits im Jahr 2005 hatte Microsoft im Rahmen des «Atlas»-Projekts einen Prototyp von clientseitigen, dass heisst JavaScript-basierten, Steuerelementen vorgestellt, welche die Datenbindung unterstützen. Diesen Prototyp hat Microsoft aber (leider) wieder verworfen.
Die in den ASP.NET 3.5 Extensions enthaltenen Dynamic Data Controls sind ein ganz anderer Ansatz, der die serverseitige Datenbindung auf das nächste Abstraktionsniveau hievt. Bisher musste der Webentwickler für jede einzelne Klasse (oder Tabelle) die Datenmasken manuell zusammenstellen. Dynamic Data Controls hingegen sind ASP.NET-Serversteuerelemente, die auf Basis einer Analyse des Datenschemas in einem LINQ-to-SQL- oder EF-Objektmodell eine Benutzeroberfläche zur Anzeige der Daten selbst zur Laufzeit erstellen. Die generierte Oberfläche bietet die Datenanzeige, die Navigation zwischen in Beziehung stehenden Objekten sowie die Änderung dieser Daten inklusive Validierung.
Gegenüber anderen Ansätzen des Rapid Application Development (RAD) unterscheidet sich der Ansatz dadurch, dass Visual Studio keine modellspezifischen Seiten generiert, die man bei einer Änderung im Modell nur schwerlich mit dem neuen Modell synchronisieren kann, sondern es kommen eine Reihe von universellen Standardvorlagen zum Einsatz.
Während sich die Dynamic Data Controls an Entwickler richten, die eine schnelle Lösung auf Kosten einer sauberen Architektur in Kauf nehmen, ist das Model-View-Controller-Framework (MVC) ein Instrument für Mehrschicht-Puristen.
Die klare Kompetenztrennung in Datenhaltung, Ansicht und Benutzerinteraktion geht allerdings derzeit unverhältnismässig stark auf Kosten des Komforts für den Entwickler, denn das MVC-Framework setzt nicht auf den bestehenden komfortablen ASP.NET-Steuerelementen auf, sondern basiert auf Platzhaltern in HTML-Tags wie einst die klassischen Active Server Pages (ASP) aus dem Zeitalter vor .NET. Wer eine Tabelle ausgeben will, kann sich also nicht auf die Abstraktion des GridView-Steuerelements stützen, sondern muss die HTML-Tags etc. verwenden und die zugehörige Schleife über die Datensätze explizit programmieren. Auch die Seitenzustandsverwaltung mit dem ASP.NET-Viewstate ist in MVC-Seiten nicht möglich. Viele andere, nicht an Steuerelemente gebundene Dienste von ASP.NET wie die Authentifizierung, Benutzerverwaltung, Sitzungsverwaltung, Zwischenspeicherung, Laufzeitüberwachung usw. stehen aber im MVC-Framework zur Verfügung.
Nachdem Webentwickler jetzt seit sechs Jahren von dem Rendering der ASP.NET-Serversteuerelemente verwöhnt wurden, ist das MVC-Framework ein schlimmer Rückfall in die Steinzeit. Seiten nach dem MVC-Modell haben neben der klaren Strukturierung nur einen weiteren Vorteil: Sie sind performanter — aber nicht wegen MVC im eigentlichen Sinne, sondern wegen des Verzichts auf die Serversteuerelemente. Für die meisten Anwendungsfälle ist das seit ASP.NET 1.0 bestehende Webforms-Modell mit der Abstraktion durch Serversteuerelemente und Viewstate schnell genug. Es ist absolut unverständlich, warum Microsoft die Kombination aus Serversteuerelementen und MVC-Pattern auf eine «spätere Version» vertagen will.
Ein zentrales Problem in ASP.NET AJAX und vielen anderen AJAX-Frameworks ist die «Zurück»-Schaltfläche in Browsern, die den Benutzer zu der letzten vollständig geladenen Webseite zurückführt und nicht zu dem vorherigen, durch einen AJAX-Aufruf erzeugten Zustand der aktuellen Seite. Hierfür bieten die ASP.NET 3.5 Extension eine Lösung, bei der der Entwickler in jedem AJAX-Schritt Zustandsinformationen an die URL (hinter dem Sonderzeichen «#») anfügen kann.
Der Entwickler muss dabei (wahlweise server- oder clientseitig) einen sogenannten Navigationspunkt festlegen und dabei alle relevanten Daten übergeben. Zu beachten hat er aber, dass die Grösse der URL auf insgesamt ein KB beschränkt ist; man sollte also die Zustandsdaten möglichst kurz halten.
System.Collections.Specialized.NameValueCollection Werte = new System.Collections.Specialized.NameValueCollection();
Werte.Add("Label1", Label1.Text);
Werte.Add("Label2", Label2.Text);
ScriptManager.GetCurrent(this).AddHistoryPoint(Werte,"Schritt #" + Wert);
Ein in der AJAX-Bibliothek hinterlegtes, browserspezifisches Skript passt beim Festlegen eines Navigationspunkts die Browser-Historie entsprechend an. Wenn der Benutzer «Zurück» oder einen bestimmten Eintrag in der Browser-Historie wählt, löst das AJAX-Framework im Programmcode wahlweise client- oder serverseitig ein Ereignis aus. Es ist dann Aufgabe des Entwicklers, die im AJAX-Zustand gespeicherten Informationen auf dem Bildschirm wiederherzustellen.
protected void ScriptManager_Navigate(object sender, HistoryEventArgs e)
{
Label1.Text = (e.State["Label1"]);
Label2.Text = (e.State["Label2"]);
}
Schliesslich bieten die ASP.NET 3.5 Extensions noch Unterstützung für Microsofts Flash-Konkurrenz Silverlight in Form von zwei Serversteuerelementen. Das Steuerelement MediaPlayer dient dem Abspielen von Video- und Audio-Dateien. Mit dem Steuerelement Silverlight kann der Webentwickler XAML-Dateien in den Browser einbinden und die Verbindung zu einer Javascript-Klasse herstellen. Voraussetzung für beide Steuerelemente ist aber, dass das Silverlight-Plug-in (http://silverlight.net/) im Browser installiert ist.
Laut der Erstankündigung der ASP.NET 2.0 AJAX Extensions sollen diese auch Unterstützung für Permalinks beinhalten. Hierzu gibt es zum Zeitpunkt der Erstellung dieses Beitrags nur eine völlig unzureichende einzeilige Beschreibung in Microsofts Dokumentation (http://quickstarts.asp.net/3-5-extensions/reference/ajaxref/T_System_Web_UI_Permalink.aspx) ohne irgendein Beispiel, sodass eine Beschreibung oder Bewertung derzeit leider noch nicht möglich ist.
Die ASP.NET 2.0 AJAX Extensions bieten interessante Funktionen sowohl für die Entwicklung im RAD-Stil als auch für die Puristen, die lieber volle Kontrolle über den gesamten Ablauf wollen und dafür längere Entwicklungszeiten in Kauf nehmen. Mit dem produktiven Einsatz sollte man sich aber noch zurückhalten, denn die aktuell verfügbare Version ist nur ein «Preview»-Release und Microsoft sichert weder zu, dass die Software stabil arbeitet noch gibt es eine Garantie, dass die hier gezeigten Funktionen Mitte 2008 erscheinen werden. In letzter Zeit hat Microsoft immer häufiger Funktionen wieder «abgesagt».
Kurz nach der TechEd Europe 2007 hat Redmond schon wieder ein ganz neues Kind ins Gespräch gebracht: Volta ist der Codename für ein Projekt (http://labs.live.com/volta/), mit dem man verteilte (Web)-Anwendungen auf .NET-Basis einfacher erstellen können soll.
Volta ist Microsofts erster Versuch, eine gemeinsame Plattform für Web- und Windows-Anwendungen zu schaffen. Ausserdem ermöglicht Volta das Aufspalten einer Anwendung in verschiedene Schichten (Tier Splitter), nachdem der Entwickler durch Annotationen im Code definiert hat, wo die Grenze zwischen Client und Server verlaufen soll.
Entwickler würden somit erheblich weniger Aufwand in die Infrastruktur einer verteilten Anwendung stecken müssen. Die Gefahr besteht aber darin, dass mit der Vereinfachung auch eine Unüberlegtheit einherkommt, was bei einer verteilten Anwendung in der Regel zu Lasten des Netzwerks und der Geduld der Benutzer geht. Aber Volta ist noch nicht einmal eine Betaversion, sondern ein Experiment, das laut Microsoft nicht zwangsläufig eines Tages in ein Produkt münden wird. Vom produktiven Einsatz von Volta auch nur (alb-)träumen zu wollen, ist also viel zu früh.
Dr. Holger Schwichtenberg (hs@IT-Visions.de) ist ein bekannter .NET-Experte, der zahlreiche Fachbücher geschrieben hat.
