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.
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" |
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.
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.