Sie sind hier: Startseite | Wissen
BASTA 2016
 

Dieser Text ist ein Auszug aus dem Buch: "Microsoft ASP.NET - Das Entwicklerbuch" (Weitere Infos hier)

Entwicklung von Websites mit ASP.NET

ASP.NET beinhaltet ein neues Programmiermodell für Webseiten, dass als Webforms-Programmiermodell bezeichnet wird. Ein Webform ist eine .aspx-Seite, die neben konventionellem HTML-Code auch so genannte Server-Steuerelemente beinhaltet.

In diesem Unterkapitel geht es zunächst um Webforms. Webservices werden später besprochen.

 

Hinweis

Ein wichtiger Hinweis vorweg: Auch wenn sich die Programmiermodelle von Windows Forms (also Windows-Anwendungen) und Webforms (Webseiten) sehr ähnlich geworden sind, so sind sie doch leider überhaupt nicht kompatibel. Die Hoffnung vieler Entwickler, in Zukunft in der Windows-Welt gestaltete Benutzeroberflächen einfach in das Web übernehmen zu können, hat sich auch mit dem .NET Framework 1.0 nicht erfüllt. In Windows Forms wird die gesamte Benutzeroberfläche durch Programmbefehle erzeugt. Der Visual Studio .NET Designer für Windows Forms generiert durch die Aktionen des Benutzers (Drag&Drop, Änderungen im Eigenschafts-Fenster, etc.) Programmcode in der gewählten Programmiersprache. Bei Webforms wird die Benutzerschnittstelle dagegen durch eine Mischung aus klassischen HTML-Code und neuen Tags (Server-Steuerelemente) beschrieben und in der Regel von dem Programmcode getrennten Datei abgelegt. Die Steuerelemente in Webforms und Windows Forms sind (aus berechtigtem Grund) verschieden. Es gibt aber keinen Wizard, der die mächtigeren Windows Forms-Steuerelemente in Webform-Steuerelemente umwandelt. Zwar wäre sicherlich nicht alles automatisch konvertierbar, jedoch hat man leider die Chance verpasst, eine Archiktektur und zugehörige Werkzeuge zu schaffen, die die Übernahme von Anwendungen vom Windows-Desktop in das Web erleichtern.

 

Abstraktion

Das Webforms-Programmiermodell realisiert eine zusätzliche Abstraktionsebene bei der Webprogrammierung. ASP-Seiten beinhalten direkt HTML-Code (oder ein anderes Ausgabeformat). ASPX-Seiten beinhalten neben konventionellem HTML-Code auch spezielle Tags mit dem Attribut runat="Server". Diese Tags werden als Server-Steuerelemente bezeichnet. Server-Steuerelemente werden nicht 1:1 an den Client übertragen, sondern auf dem Server findet zunächst eine Umwandlung statt. Es wird erst zur Laufzeit entschieden, ob das Ausgabeformat reines HTML ist, oder HTML mit Script-Code (Dynamic HTML) oder WML oder cHTML etc. Aus jedem Server-Steuerelement werden ein oder mehrere Tags generiert. Der Client enthält nur Tags (und ggf. clientseitigen Scriptcode), weil alle Server-Steuerelemente bereits auf der Serverseite in Tags umgesetzt werden. Zum Beispiel wird aus dem Server-Steuerelement <asp:Textbox> bei der Umwandlung das HTML-Tag <input type=text>.

 

Abbildung: Abstraktion in ASP.NET

Objektorientierung

Das Webform-Programmiermodell in ASP.NET ist objektorientiert und ereignisbasiert (ähnlich der Entwicklung von Windows32-Anwendungen mit Visual Basic 6.0/.NET). Bei den Server-Steuerelementen sind zwei Darstellungsformen zu unterscheiden: In der ASPX-Seite sind Server-Steuerelemente Tags mit dem Attribut runat="server". Im Rahmen der serverseitigen Programmierung werden die Server-Steuerelemente durch .NET-Objekte repräsentiert mit Attributen, Methoden und Ereignissen. Ein Webform-Objekt ist eine Hierarchie von Server-Steuerelement-Objekten.

Deklaration in der ASPX-Seite (Server-Steuerelement-Tags)

Verwendung im Programmcode (Server-Steuerelement-Objekt)

<asp:TextBox
id="Vorname"
runat="server">
kein Name eingetragen
</asp:TextBox>

Vorname.Text = "Holger"

 

Hinweis

Der objektorientierte programmatische Zugriff auf den Inhalt der Webseite löst das sequentielle Erzeugen von HTML-Quellcode ab, dass im klassischen ASP und verwandten Techniken wie PHP verwendet wird. Microsoft macht dazu die Werbeaussage, dass in ASP.NET gegenüber ASP zwischen 40 und 70% weniger Programmcode geschrieben werden muss.

 

Anhand eines einfachen Beispiels (/Kapitel01/ASP.NET/Programmiermodell.aspx) kann der Unterschied in der Programmierung zwischen dem klassischen Hinausschreiben von HTML und der objektorientierten Programmierung in ASP.NET gezeigt werden. Die Anwendung erhöht den Wert in einem Textfeld bei jedem Roundtrip um eins. Wenn die Zahl gerade ist, bekommt das Textfeld einen gelben, sonst einen grünen Hintergrund.

Abbildung: Beispiel Zähler erhöhen in ASP vs. ASP.NET

<!--- Formulardefinition ASP -->

<FORM id="Form1" method="post">

<INPUT name="count1" type="text"      value="<%=Request("count1")+1%>"

<%if Request("count1") mod 2 = 0 then%>

style="BACKGROUND-COLOR: yellow">

<%else%>

style="BACKGROUND-COLOR: greenyellow">

<%end if%>

<BR>

<INPUT type="submit" value="erhöhen (ASP)" name="Submit1">

</FORM>

Im Kontrast dazu folgt nun die elegantere Lösung in ASP.NET.

<!--- Formulardefinition ASP.NET -->

<FORM id="Form2" method="post" runat="server">

<asp:TextBox id="TextBox1" runat="server">1</asp:TextBox>

<asp:Button id="Button1" runat="server" Text="erhöhen (ASP.NET)"></asp:Button>

</FORM>

<script runat="server">

' === Ereignisbehandlung

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

    TextBox1.Text = CInt(TextBox1.Text) + 1

    If CInt(TextBox1.Text) Mod 2 = 0 Then

      TextBox1.BackColor = System.Drawing.Color.Yellow

    Else

      TextBox1.BackColor = System.Drawing.Color.GreenYellow

    End If

End Sub

</script>

 

In ASP.NET ist es auch weiterhin erlaubt, reines HTML sowie Render- und Display-Blöcke alternativ zu Server-Steuerelementen zu verwenden. Diese Inhalte können dann aber nicht über ein Objekt auf der Serverseite verändert werden. Um die gesamte Seite objektorientiert manipulierbar zu machen, muss man die Server-Steuerelemente Label oder PlaceHolder verwenden. Allerdings benötigen diese Server-Steuerelemente mehr Rechenzeit als statisches HTML. Der Einsatz sollte daher wohl überlegt sein.

 

Ereignisbehandlung

Der gesamte Programmcode liegt bei ASP.NET in serverseitigen Ereignisbehandlungsroutinen für die Server-Steuerelement-Ereignisse. Es gibt zwei Arten von Ereignissen:

¨     Ereignisse, die im Rahmen der verschiedenen Verarbeitungsschritte einer ASPX-Datei auf dem Server ausgelöst werden (z.B. Page_Load(), TextBox1_PreRender())

¨     Ereignisse, die Aktionen und Zustandsänderungen (z.B. neuen Werten) auf dem Client entsprechen (z.B. Button1_Click(), Textbox1_TextChanged())

Letztere Ereignisse sind aus der Sicht von ASP.NET Pseudo-Ereignisse, weil nicht jede Änderung in einem Eingabefeld im Browser sofort an den Client übertragen wird. Die meisten ASP.NET-Ereignisse werden daher zeitverzögert ausgelöst. Eine Datenübertragung vom Browser an den Server findet im Rahmen einer erneuten HTTP-Anfrage (Roundtrip) zum Server statt. Ein Roundtrip wird normalerweise durch einen Klick auf eine Submit-Schaltfläche (HTTP-GET oder HTTP-POST) oder den Klick auf einen Link (HTTP-GET) ausgelöst. Zum Webforms-Programmiermodell gehört es, dass alle Roundtrips auf einem HTTP-POST basieren, man spricht von einem Postback. Durch clientseitigen Scriptcode wird erreicht, dass ein Klick auf einen Link oder die Wertänderung in einem Eingabefeld auch einen Postback auslösen kann. Ob ein Server-Steuerelement bei einem Klick oder einer Wertänderung einen Postback auslöst, ist konfigurierbar (Attribut AutoPostBack).

Die folgende Abbildung zeigt ein Szenario, bei dem ein Postback durch einen Klick auf "Button1" ausgelöst wird. Die zuvor vorgenommenen Änderungen an "Textbox1" und "List1" bemerkt der Server erst nach dem Roundtrip. Der Server erhält keine Ereignismeldungen im eigentlichen Sinne, weil es in HTML/HTTP keine solche Ereignismeldungen vom Client an den Server gibt. Der Server erhält lediglich den aktuellen Inhalt der Eingabefelder, die er mit dem letzten Inhalt der Felder (die im versteckten Feld Viewstate gespeichert werden) vergleicht. Dadurch kann die ASP.NET-Engine erkennen, welche Aktionen auf dem Client ausgeführt wurden. Er löst dann aber zeitverzögert die entsprechenden Ereignisbehandlungsroutinen Textbox1_TextChanged(), List1_SelectedIndexChanged() und Button1_Click() aus. Selbstverständlich kann so nicht bemerkt werden, wenn ein Benutzer einen Wert in einem Eingabefeld ändert und dann vor dem Absenden den alten Wert wiederherstellt.  Da aus der Sicht des Servers nichts passiert ist, wird kein Ereignis auf dem Server ausgelöst. Im Dynamic HTML würden in diesem Fall zwei Änderungsereignisse auf dem Client ausgelöst.

 

Abbildung: Ereignisbasierte Programmierung

Ereignisse können an übergeordnete Server-Steuerelemente weitergeleitet werden. Beispielsweise wird der Klick auf einen Link in einem DataGrid als ein Ereignis des DataGrid aufgefasst.

Seitenübergänge

Damit die serverseitigen Ereignisse abgearbeitet werden können, wird im Webforms-Programmiermodell bei einem Postback immer die gleiche Seite wieder selbst aufgerufen. Ein Seitenübergang zur nächsten Seite wird dann serverseitig (durch Übergabe der Programmkontrolle an die nächste ASPX-Seite) oder durch Umleitung des Clients (Senden des HTTP-Statuscode 302 an den Client) ausgeführt. Daher spricht man bei ASP.NET-Webforms auch von einer Postback-Architektur.

Erst nachdem die Ereignisse abgearbeitet wurden, erfolgt der Aufruf der nächsten Seite (wahlweise serverseitig durch Server.Transfer() oder der mit Hilfe des Clients durch einen Response.Redirect()). In Webforms es gibt daher in serverseitigen <Form>-Tags kein Action-Attribut. Das Action-Attribut anzugeben hätte keine Wirkung. Auch bei einigen Formen von Hyperlinks wird (unter Einsatz von Client-Scripten) zunächst die aktuelle Seite erneut aufgerufen.

Abbildung: Seitenübergänge im Webforms-Programmiermodell

Programmiersprachen

ASP war nicht auf eine Programmiersprache beschränkt, prinzipiell konnte jede Programmiersprache verwendet werden, die dem Active Scripting-Modell entsprechende Schnittstellen bot. In ASP.NET kommen dagegen .NET-kompatible Sprachen (also Sprachen, die gemäß der CLS entwickelt wurden) zum Einsatz. Damit können auch Sprachen benutzt werden, die mehr Objektorientierung und eine strenge Typisierung bieten.

CLS-Sprachen sind die in der nachfolgenden Tabelle genannten Sprachen.

.NET-Sprachen von Microsoft

Andere .NET-Sprachen

CSharp (C#)
Visual Basic .NET (VB.NET)
JScript .NET
JSharp (J#)

Alice
APL
Cilk
Cobol
Eiffel
Haskell
Mercury 
Mondrian
Oberon
O'Cami
Oz
Pascal
Perl
Python
Scheme
SmallTalk
SML

Im Gegensatz zu ASP, wo eine Mischung mehrerer Sprachen auf einer Seite möglich war, kann in ASP.NET auf einer einzelnen Seite nur noch eine Programmiersprache verwendet werden. Dies kann umgangen werden durch die Erstellung benutzerdefinierter Server-Steuerelemente. ASP.NET erlaubt es, innerhalb einer Webanwendung verschiedene Webseiten in verschiedenen Sprachen zu erstellen. Beim Einsatz von Visual Studio .NET ist das allerdings nicht möglich: Eine Webanwendung entspricht einem Visual Studio .NET-Projekt und ein Projekt kann in der Entwicklungsumgebung immer nur eine Sprache verwenden.

 

Hinweis

Es ist allerdings möglich, Funktionen in Komponenten auszulagern, die in einer anderen Sprache erstellt werden (und im Rahmen eines anderen Projekts übersetzt werden).

 

 

Während der Programmcode in ASP-Seiten interpretiert wird, kommen in ASP.NET Compiler zum Einsatz. Die Kompilierung erfolgt in drei Schritten, die Schritte 1 und 2 werden dabei nur einmal ausgeführt, solange sich eine Seite nicht geändert hat:

1.     Zunächst generiert der ASP.NET-Arbeitsprozess aus dem beschreibenden Inhalt der ASPX-Seite (also HTML-Tags und Server-Steuerelement-Tags) neuen Programmcode. Dabei wird aus der ASPX-Seite der Quellcode für eine Klasse generiert, die von der FCL-Klasse System.Web.UI.Page erbt.

2.     Dann wird zunächst in die Microsoft Intermediate Language (MSIL) kompiliert. Diese Kompilierung findet entweder zur Übersetzungszeit statt oder zur Laufzeit beim ersten Aufruf. In beiden Fällen wird eine Assembly im Dateisystem in einem speziellen Ordner abgelegt, sodass beim nächsten Aufruf die erneute Übersetzung nicht notwendig ist. Diese Übersetzung wird von einem Kommandozeilencompiler der jeweiligen Sprache ausgeführt. Den Anstoß zu dieser Kompilierung gibt der ASP.NET-Arbeitsprozess.

3.     Beim Aufruf der Seite wird der MSIL-Code dann blockweise durch den in die CLR eingebauten Just-in-Time-Compiler in Native Code verwandelt. Trotz des Umwegs über die Zwischensprache MSIL ist die Ausführung von ASP.NET-Seiten wesentlich schneller als die Ausführung von ASP-Seiten.

Abbildung:Übersetzungsvorgang einer ASPX-Seite




 

ASP.NET ist in der Lage, eine wesentlich höhere Performance als klassische ASP-Seiten zu erreichen. Erfolgsfaktor ist dabei jedoch nicht in erste Linie die Kompilierung, sondern das frühe Binden. Dies kann an einem einfachen Schleifendurchlauf gezeigt werden.

 

Vorgehen

Implementierung

Dauer für 50000000 Schleifendurchläufe

ASP

<%

Dim b, a, start, ende, anzahl

Anzahl = 50000000

Response.Write("Schleifendurchläufe: " & anzahl & "<hr>")

start = now

for a = 1 to anzahl

  b = b + a

next

ende = now

Response.Write ("Start: " & start & "<br>")

Response.Write ("Ende: " & ende & "<br>")

Response.Write ("Ausführungsdauer: " & DateDiff("s",start,ende))

%>

33 Sekunden

ASP.NET mit später Bindung

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

    Dim b, a, start, ende, Anzahl

    Anzahl = 50000000

    Response.Write("Schleifendurchläufe: " & Anzahl & "<hr>")

    start = DateTime.Now

    For a = 1 To Anzahl

      b = b + a

    Next

    ende = DateTime.Now

 

    Response.Write("Start: " & start & "<br>")

    Response.Write("Ende: " & ende & "<br>")

    Response.Write("Ausführungsdauer: " & DateDiff("s", start, ende))

End Sub

61 Sekunden

ASP.NET mit früher Bindung

Wie oben, jedoch:

 

Dim b As Int64, a As Int64, start As DateTime, ende As DateTime, Anzahl As Int64

 

< 1 Sekunde

Trennung von Layout und Programmcode

In ASP.NET besteht eine Möglichkeit, den HTML-Code (das Layout) und den Programmcode in zwei verschiedene Dateien aufzuteilen. Dies wird möglich durch die ereignisorientierte Programmierung: Die Ereignisbehandlungsroutinen sind nicht mit dem HTML-Code vermischt und können daher in eine eigene Datei verlagert werden. Dies nennt man Code-Behind-Modell, das auch schon in VBA und VB6 verwendet wird.

Die nachfolgende Grafik zeigt die Entsprechung zwischen einer ASP-Datei, in der HTML-Code und Programmcode (kursive Schrift) gemischt sind, und einer ASPX-Seite mit sogenannter Code-Behind-Datei. Die Code-Behind-Datei hat im Regelfall den gleichen Namen wie die ASPX-Datei mit einer zusätzlichen Dateiextension, die die Sprache festlegt (z.B. name.aspx.vb oder name.aspx.cs). Die Verbindung zwischen der ASPX-Datei und einer Code-Behind-Datei wird durch das Attribut CodeBehind in der @Page-Direktive in der ASPX-Seite hergestellt, sodass auch ein anderer Dateiname möglich ist.

 

Abbildung: Trennung von Layout und Code in ASP.NET

Das Code-Behind-Modell ist nur eine Option. Nach wie vor kann der Programmcode auch in der ASPX-Datei enthalten sein, selbst wenn eine Code-Behind-Datei existiert. Wenn keine Code-Behind-Datei existiert, dann spricht man vom Single-File-Modell.

Technisch realisiert wird das Code-Behind-Modell durch Vererbung. Normalerweise wird eine ASPX-Seite beim Aufruf in eine Klasse umgewandelt, die von der FCL-Klasse System.Web.UI.Page erbt. In dem Code-Behind-Modell implementiert die Code-Behind-Datei eine Klasse (üblicherweise mit dem Namen „Webname.Seitenname"), die in der Vererbungshierarchie zwischen der Page-Klasse und der Klasse aus der ASPX-Seite geschaltet ist. Die Code-Behind-Klasse erbt also von System.Web.UI.Page und die Klasse aus der ASPX-Seite erbt von der Code-Behind-Klasse.

Abbildung: Vererbungsmodelle

Die folgende Grafik zeigt den Übersetzungsvorgang einer ASPX-Seite mit Code-Behind-Datei. Um die Komplexität der Abbildung nicht weiter zu erhöhen, wurde ein Sonderfall nicht dargestellt: Die Code-Behind-Datei muss nicht zur Entwicklungszeit kompiliert werden. Sie kann (durch die Option src="name.aspx.vb" in der @Page-Direktive statt CodeBehind="name.aspx.vb") ebenfalls zur Entwicklungszeit kompiliert werden. Dann erhält die Assembly auch einen von der ASP.NET-Engine vergebenen Namen und landet wie die Assembly zu ASPX-Datei im Verzeichnis %FRAMEWORK%/Temporary ASP.NET Files.

.

Abbildung: Kompilierung

 

Die Entwicklungsumgebung Visual Studio .NET verwendet im Standard immer Code-Behind-Dateien, während der Freeware-Ableger Web Matrix immer nur Single-File-Dateien unterstützt.

 

Steuerelement-Typen

Es gibt zwei Typen von Server-Steuerelementen: HTML-Server-Steuerelemente und Web-Server-Steuerelemente.




Abbildung: Überblick über Steuerelemente in ASP.NET

Web-Server-Steuerelemente sind die mächtigste Form der Server-Steuerelemente. Ein Web-Server-Steuerelement erkennt man an dem Namespace "asp", der dem Tagnamen voran steht.

<asp:Label runat=Server id="Label1">
Bitte URL eingeben:</asp:Label>

<asp:TextBox id="Textbox1"
runat="server">HTTP://...</asp:TextBox>

<asp:Button id="Button1" runat="server"
Text="OK"></asp:Button>

HTML-Server-Steuerelemente sind eine konzeptionelle Mischung aus den clientseitigen Standard-HTML-Elementen und den Web-Server-Steuerelementen. Das Tag für ein HTML-Server-Steuerelement entspricht einem normalen HTML-Tag, nur mit dem Zusatzattribut runat="server". Diese Steuerelemente besitzen eine serverseitige Ereignisbehandlung und können wie Web-Server-Steuerelemente objektorientiert verändert werden. Sie erlauben auch die Datenbindung.

Es besteht eine 1:1-Abbildung zwischen HTML-Server-Steuerelementen und HTML-Tags: Bei der Umsetzung der Seite erzeugt ASP.NET aus jedem HTML-Server-Steuerelement genau ein Tag. Dazu ein Beispiel:

<P id="HSC_Text" runat="server">Bitte URL eingeben:</P>

<INPUT type="text" id="HSC_Feld" name="HSC_Feld" runat="server" value="HTTP://...">

<INPUT type="button" value="OK" name="HSC_Button" id="HSC_Button" runat="server">

HTML-Server-Steuerelemente unterliegen gegenüber Web-Server-Steuerelementen folgenden Einschränkungen:

¨     Sie bieten keine Abstraktion vom Ausgabeformat. Ein HTML-Server-Steuerelement wird immer auch als HTML-Tag ausgegeben. Es gibt keine browserspezifische Ausgabe.

¨     Sie bieten keine Ereignisweiterleitung an übergeordnete Server-Steuerelemente.

¨     Die Eingabefelden bietet keine Möglichkeit zum direkten Postback (kein AutoPostBack-Attribut). Lediglich Schaltflächen und (manche) Hyperlinks lösen einen Postback aus.

HTML-Server-Steuerelemente bieten aber auch drei Vorteile gegenüber Web-Server-Steuerelementen:

¨     Die Migration von klassischem ASP- oder HTML-Code ist einfacher, durch die 1:1-Abbildung zwischen HTML-Tag und HTML-Server-Steuerelement. Visual Studio .NET unterstützt die Migration durch eine Konvertierungsfunktion im Webform-Designer (Kontextmenüeintrag Als Serversteuerung ausführen).

¨     Die Hinterlegung clientseitiger Scripts ist einfacher, da es keine Umwandlung des Quellcode-Tags auf Serverseite gibt.

¨     Es gibt einige HTML-Tags, die nur durch ein HTML-Server-Steuerelement abgebildet werden können, weil es dafür (noch) kein Web-Server-Steuerelement gibt.

 

Details zu den einzelnen Steuerelementen erfahren Sie in ì Kapitel 2.

 

Besondere Steuerelemente

ASP.NET bietet für Server-Steuerelemente zwei wichtige Funktionen an, die die tägliche Arbeit des Entwicklers sehr vereinfachen:

Validierungs-Server-Steuerelemente: Es gibt Server-Steuerelemente, deren Aufgabe es ist, den Inhalt anderer Server-Steuerelemente nach bestimmten Kriterien zu prüfen. Kriterien sind beispielsweise ob ein Feld nicht leer ist, ob zwei Felder den gleichen Inhalt haben oder ob der Wert in einem bestimmten Wertebereich liegt. Mit Hilfe von regulären Ausdrücken oder eigenen Validierungsfunktionen können auch komplexere Regeln definiert werden. Schlägt die Gültigkeitsprüfung fehlt, geben die Validierungs-Server-Steuerelemente eine beliebige Meldung aus. Ein Server-Steuerelement mit Namen ValidationSummary kann die Meldungen aller einzelnen Validations-Steuerelemente zusammenfassen.

Sie arbeiten auf Wunsch nicht nur serverseitig, sondern durch den Einsatz von clientseitigem Script-Code erzeugen Sie eine Fehlermeldung ohne Postback zum Server bzw. verhindern sogar den Postback zum Server bevor alle Eingaben korrekt sind.

ASP.NET unterstützt auch die Bindung von Datenquellen an Steuerelemente, die Datenmengen ausgeben können (z.B. Listen und Tabellen). Dadurch entfällt das zeilenweise Auslesen der Datenquelle und zeilenweise Erzeugen der Ausgabe. Diese Technik ist bereits aus anderen Umgebungen (z.B. Microsoft Access Formulare, Visual Basic 6.0, Visual C++ 6.0, Internet Explorer Scripting) bekannt.

 

Die Validations-Steuerelemente werden in ì Kapitel 3 beschrieben. Kapitel 6 widmet sich ausführlich dem Datenzugriff einschließlich den datengebundenen Steuerelementen.

 

 

Zustandsverwaltung

ASP.NET bietet wie das klassische ASP eine Zustandsverwaltung (State Management) auf Basis von Sitzungen (Sessions) an. Während diese Session in ASP auf einem Session-Cookie (Speicherung einer eindeutigen Sitzungs-ID in einem Cookie auf dem Client) beruhen, bietet ASP.NET alternativ die Speicherung und Weiterreichung der Sitzungs-ID in der URL an. Diese Technik wird auch als URL-Rewriting bezeichnet, weil jeder Seitenübergang auf einer dynamisch generierten URL beruht. ASP.NET kümmert sich um den Einbau der Sitzungs-ID in die URL, sodass für den Entwickler kein Zusatzaufwand entsteht. Wie im klassischen ASP kann der ASP.NET-Entwickler beliebige Werte in der Session-Collection ablegen - der ASP.NET-Arbeitsprozess kümmert sich um die Zuordnung zwischen Sitzungs-ID und den dazu abgelegten Werten. Auch die anwendungsweite Collection Application ist vorhanden.

Außerdem bietet ASP.NET die Option, die Sitzungstabelle (die Tabelle mit der Zuordnung zwischen Sitzungs-ID und den dort angelegten Attribut- Wert-Paaren) auf einem dedizierten Server zu speichern oder in einer Microsoft SQL Server-Datenbank, sodass die Tabelle von allen Server einer Webfarm genutzt werden kann.

Neben dem aus dem klassischen ASP bekannten Sitzungsverwaltung sorgt ASP.NET zusätzlich auch automatisch dafür, dass der Zustand von Server-Steuerelementen zwischen zwei Seitenaufrufen erhalten bleiben, d.h. wenn ein Attribut eines Server-Steuerelemente bei einem Seitenaufruf geändert wurde (egal, ob der Wert oder ein Gestaltungs-Attribut), so ist dieser Zustand auch nach einem Postback noch vorhanden, ohne dass das Attribut erneut gesetzt werden müsste. Dies realisiert ASP.NET technisch durch ein verstecktes HTML-Feld mit der ID "__Viewstate". Der View State ist die Zusammenfassung der Zustände aller Server-Steuerelemente. Man kann den Viewstate auch zur Speicherung anderer Werte verwenden. Dazu gibt es eine Collection mit Namen ViewState. Allerdings gilt der Viewstate nur für eine Seite. Bei einem Seitenübergang geht er verloren.

Die dritte neue Möglichkeit zur Zustandsverwaltung ist die Cache-Collection. Sie hat eine ähnliche Funktion wie die Application-Collection, nämlich die Speicherung sitzungsübergreifender (also globaler) Objekte. Anders als bei der Application-Collection kann ein Objekt mit einem Verfallskriterium ausgestattet werden. Ein Verfallskriterium ist nicht nur ein Zeitraum, sondern auch das Ändern einer Datei oder das Ändern eines anderen Objekts im Cache. Somit kann die Cache-Collection zur Zwischenspeicherung häufig genutzter Objekte dienen, auch wenn diese sich (gelegentlich) ändern.

 

Mehr dazu erfahren Sie in Kapitel 3.

 

Verwendbare Objekte und Funktionen

ASP.NET kann weiterhin COM-Komponenten nutzen. Zusätzlich kann ASP.NET jetzt (selbstverständlich) auch .NET-Komponenten und (nicht selbstverständlich) über den in die CLR eingebauten Plattform Invoke-Mechanismus Funktionen aus C-Style-DDLs aufrufen. Dies bedeutet, dass ASP.NET nicht nur die komplette .NET Framework Class Library (FCL) zur Verfügung steht, sondern auch eine große Menge an Funktionen aus dem Win32-API. Da der Zugriff auf COM-Komponenten und C-Style-DLLs einen  (ressourcenintensiveren) Übergang zwischen Managed Code und Unmanaged Code darstellt, ist die Verwendung von .NET-Komponenten stets die beste Wahl.

Unter ASP mussten die verwendeten COM-Komponenten global registriert sein. ASP.NET folgt dem Konzept des .NET Framework und präferiert lokale Komponenten im Anwendungsverzeichnis der Webanwendung. Im Standard liegen lokale Komponenten im Unterverzeichnis /bin direkt unterhalb der Wurzel der Webanwendung. Natürlich kann ASP.NET auch .NET-Komponenten aus dem Global Assembly Cache (GAC) nutzen.

Auch die eingebauten Objekte (Intrinsic Objects) von ASP.NET bieten mehr als ihre Vorgänge aus dem klassischen ASP. Es gibt nun ein komplettes Objektmodell, an dessen Spitze die Klasse System.Web.UI.Page steht. Jede ASPX-Webseite ist eine Klasse, die von dieser Klasse erbt. Die altbekannten eingebauten Objekte (Response, Request, Server, Application) und neue Intrinsic Objects wie ViewState, Cache und User sind Unterobjekte der Page-Klasse und stehen damit in allen ASPX-Webseiten zur Verfügung. Die altbekannten Objekte wurden erweitert, um neue Attribute und Methoden. Auch bietet die Page-Klasse weitere Objekte an (z.B. Trace, User, Cache, Context).

 

Mehr dazu erfahren Sie in ì Kapitel 4.

 

Konfiguration

Die Konfiguration von ASP erfolgt im Wesentlichen über den Internet-Dienstemanager, der seine Konfigurationsinformationen in der sogenannten IIS-Metabase abspeichert. Die von ASP genutzten COM-Komponenten werden über die Registry konfiguriert.

ASP.NET geht einen anderen Weg: Wie im .NET Framework üblich, werden alle Konfigurationsinformationen in XML-Datenstrukturen als Dateien im Dateisystem gespeichert. Für ASP.NET gibt es zwei wichtigste XML-Konfigurationsdateien:

¨     Machine.config: Pro Computer gibt es genau eine solche Datei im %Framework%/Config-Verzeichnis. Die Machine.config enthält globale Einstellungen und Standardeinstellungen, die in einer web.config überschrieben werden können.

¨     web.config: Es kann pro Web-Anwendung eine oder mehrere web.config-Dateien geben. In jedem Verzeichnis der Web-Anwendung ist eine solche Datei erlaubt. Sie gelten für das Verzeichnis und alle untergeordneten Verzeichnisse. Wenn eine web.config-Datei existiert, aber für eine bestimmte Einstellung kein Wert festgelegt ist, dann gilt der Wert aus der übergeordneten web.config-Datei bzw. der maschine.config, falls es sich um die web.config aus dem Wurzelverzeichnis der Webanwendung handelt.

Zu den neuen Konfigurationseinstellungen gehört auch, dass es neben der Basic Authentication, NTML-Authentifizierung und Kerberos nun zwei weitere Authentifizierungsmechanismen gibt: den universellen Authentifizierungsdienst Microsoft Passport oder selbstdefinierte Webforms, die einen Anmeldedialog enthalten.

ASP.NET ist so konzipiert, dass das XCOPY-Deployment des .NET Framework auch für Webanwendungen funktioniert. Voraussetzung ist lediglich, dass das Verzeichnis der Anwendung im Internet Information Server als virtueller Webserver oder virtuelles Verzeichnis freigegeben ist. Das virtuelle Verzeichnis sollte zudem eine IIS-Anwendung sein.

 

Mehr über die Verbreitung und Konfiguration von ASP.NET-Webanwendungen erfahren Sie in ì Kapitel 4.

 

Caching

ASP.NET ermöglicht das Caching des von einer Assembly für den Webserver erzeugten Ausgabe. Normalerweise wird die Ausgabe sofort nach der Weiterleitung an den Webserver verworfen. Im Rahmen einer Seitendirektive (<%@OutputCache>) kann definiert werden, dass die Ausgabe eine definierbare Zeit lang im Speicher vorgehalten wird zur Beantwortung gleichartiger Anfragen. Ob zwei Anfragen als gleich betrachtet werden, kann dabei definiert werden. So kann beispielsweise festgelegt werden, dass die übergebenen Parameter berücksichtigt werden (die Seiten also für jede Parameterkombination einzeln gecached werden) oder zwei unterschiedliche Browser bzw. Browserversionen nicht den gleichen HTML-Code erhalten (die Seiten also für jeden Browser einzelne gecached werden). Mehr dazu erfahren Sie in ì Kapitel 4.

 

Neu in ASP.NET 1.1 ist, dass der Output Cache im HTTP-Stack (http.sys) im Kernel Mode liegt. Damit kann noch eine wesentlich höhere Performance erreicht werden als beim Caching im Rahmen des ASP.NET-Arbeitsprozesses in ASP.NET 1.0.

 

Fehlersuche

Die Fehlersuche in ASP.NET ist gegenüber ASP wesentlich verbessert durch sehr viel ausführlichere Fehlermeldungen, einen eingebauten Tracing-Mechanismus und einen komfortablen Debugger in Visual Studio .NET.

 

Mehr zum Thema Debuggen erfahren Sie in Kapitel 2.

 

 

Autor: Holger Schwichtenberg
Dieser Text ist ein Auszug aus dem Buch: "Microsoft ASP.NET - Das Entwicklerbuch" (Weitere Infos hier)