Verarbeiten von Web Forms-Seiten

Artikel
04/01/2008

Im Allgemeinen ist der Lebenszyklus einer Web Forms-Seite ähnlich lang wie ein beliebiger Webprozess, der auf dem Server ausgeführt wird. Bestimmte Eigenschaften der Webverarbeitung – über HTTP-Protokoll übergebene Informationen, die statusfreie Beschaffenheit von Webseiten, usw. – treffen sowohl auf Web Forms-Seiten als auch auf die meisten Webanwendungen zu.

Das ASP.NET-Seitengerüst führt viele Webanwendungsdienste für Sie aus. Beispielsweise erfasst das ASP.NET-Seitengerüst mit der Web Forms-Seite gesendete Informationen, extrahiert die relevanten Werte und stellt die Informationen über Objekteigenschaften zur Verfügung.

Es ist wichtig, dass Sie die Reihenfolge der Ereignisse bei der Verarbeitung einer Web Forms-Seite verstehen. Mit diesen Kenntnissen können Sie die Web Forms-Seiten und Webanwendungen effektiver programmieren.

Der Lebenszyklus einer Web Forms-Seite

Es ist sinnvoll, sich die grundlegenden Merkmale der Funktionsweise von Web Forms-Seiten in Webanwendungen zu vergegenwärtigen, bevor Sie die Einzelheiten über das Innenleben einer Seite bei der Verarbeitung näher untersuchen.

Schleifen

Die Aufteilung der Arbeit in einer Web Forms-Seite ist einer der wichtigsten Aspekte, die Sie verstehen müssen. Der Browser zeigt dem Benutzer ein Formular an, und der Benutzer interagiert mit dem Formular, worauf das Formular an den Server zurückgesendet wird. Da die gesamte Verarbeitung, die Interaktion mit Serverkomponenten beinhaltet, auf dem Server stattfinden muss, muss das Formular für jede zu verarbeitende Aktion an den Server gesendet, verarbeitet und an den Browser zurückgesendet werden. Diese Ereignisreihenfolge wird als Schleife bezeichnet.

Hinweis ** **Sie können ein Clientskript in Web Forms erstellen, das für die Überprüfung von Benutzereingaben und für einige Typen der Benutzeroberflächenprogrammierung nützlich ist. Clientskripts interagieren nicht mit Severkomponenten.

Stellen Sie sich ein Geschäftsszenario vor: Ein Benutzer gibt eine Bestellung ein und die Verfügbarkeit des bestellten Artikels soll bestätigt werden. Die Anwendung sendet also an geeigneter Stelle im Auftragseingangsprozess des Benutzers die Seite an den Server. Ein Serverprozess prüft die Bestellung, führt eine Inventarsuche und möglicherweise eine in der Geschäftslogik definierte Aktion aus (wie das Ändern der Seite, um einen Fehler anzuzeigen) und sendet dann die Seite an den Browser zurück, damit der Benutzer fortfahren kann.

Schleife

In Web Forms ergeben die meisten Benutzeraktionen wie das Klicken auf eine Schaltfläche eine Schleife. Aus diesem Grund sind die in ASP.NET-Serversteuerelementen verfügbaren Ereignisse i. d. R. auf Klickereignisse beschränkt. Die meisten Serversteuerelemente machen ein Klickereignis verfügbar, für das eine ausdrückliche Benutzeraktion erforderlich ist.

Ebenso machen Serversteuerelemente keine häufig auftretenden Ereignisse wie onmouseover verfügbar, da bei jedem Auslösen eines solchen Ereignisses eine andere Schleife zum Server stattfinden würde, was die Reaktionszeit im Formular erheblich beeinträchtigen würde.

Erneutes Erstellen der Seite (Anzeigestatus und Statusverwaltung)

In jedem Webszenario werden die Seiten in jeder Schleife neu erstellt. Sobald der Server die Verarbeitung und das Senden der Seite an den Browser abgeschlossen hat, werden die Seiteninformationen verworfen. Durch das Freigeben von Serverressourcen nach jeder Anforderung, kann eine Webanwendung Hunderte und Tausende von Benutzern gleichzeitig unterstützen. Beim nächsten Senden der Seite beginnt der Server wieder mit dem Erstellen und Verarbeiten der Seite. Aus diesem Grund sind Webseiten statusfrei – die Werte von Seitenvariablen und Steuerelementen werden nicht auf dem Server gespeichert.

**Hinweis **Der Server kann so konfiguriert werden, dass Seiteninformationen im Cachespeicher zwischengespeichert werden, um die Seiten zu optimieren. Allerdings ist es für die Anwendungsprogrammierung am Besten, diese Informationen zu löschen, sobald der Server die Verarbeitung abgeschlossen hat.

In einer traditionellen Webanwendung verfügt der Server nur über die Informationen eines Formulars, die der Benutzer den Steuerelementen im Formular hinzugefügt hat, da die Informationen beim Senden des Formulars an den Server übermittelt werden. Andere Informationen wie Variablenwerte und Eigenschafteneinstellungen werden verworfen.

ASP.NET vermeidet diese Einschränkungen wie folgt:

Seiten- und Steuerelementeigenschaften werden zwischen Schleifen gespeichert. Dies wird als Speichern des Anzeigestatus des Steuerelements bezeichnet.
ASP.NET enthält Statusverwaltungsfunktionen, mit denen Sie eine eigene Variable und anwendungs- oder sitzungsspezifischen Informationen zwischen Schleifen speichern können.
ASP.NET stellt fest, wenn ein Formular erstmals angefordert oder gesendet wird. Somit können Sie die entsprechende Programmierung vornehmen. Denn möglicherweise soll ASP.NET sich beim Rücksenden einer Seite anders verhalten als bei der anfänglichen Anforderung.

Vorteile eines ereignisgesteuerten Modells gegenüber einem linearen Verarbeitungsmodell

Wenn Sie mit Active Server Pages (ASP) Erfahrung haben, erkennen Sie, dass es sich bei ASP um ein lineares Verarbeitungsmodell handelt. Eine ASP-Seite wird in der Reihenfolge von oben nach unten verarbeitet. Jede ASP-Codezeile und statische HTML-Zeile wird in der Reihenfolge verarbeitet, in der sie in der Datei auftritt. Benutzeraktionen veranlassen, dass die Seite in einer Schleife an den Server gesendet wird. Da diese Aktion eine Schleife hervorruft, muss der Server die Seite neu erstellen. Nachdem die Seite neu erstellt wurde, wird sie in derselben Reihenfolge wie zuvor verarbeitet, also von oben nach unten. Daher weist die Seite kein tatsächlich ereignisgesteuertes Verhalten auf. Wenn Sie ein ereignisgesteuertes Element erstellen möchten, müssen Sie es ausdrücklich entwerfen. Außerdem müssen Sie den Seiten- und Steuerelementstatus auf der Basisebene explizit verwalten. Dieses Modell schränkt die Vielfalt der Benutzeroberflächen ein, die erstellt werden können, und erhöht die Komplexität des Codes, der für die Unterstützung erforderlich ist.

Im Vergleich dazu enthält ein ereignisgesteuertes Modell wie in einer herkömmlichen Visual Basic-Anwendung programmierbare Elemente, die initialisiert und im Formular angezeigt werden. Benutzer interagieren mit den Elementen, wodurch Ereignisse ausgelöst werden, die wiederum Ereignishandler aufrufen. Dieses Modell unterstützt wirklich ereignisgesteuertes Verhalten, das aufgrund seines Entwurfs die Vielfalt der Benutzeroberflächen, die erstellt werden können, erheblich erweitert, und verringert die Komplexität des Codes, der für die Unterstützung erforderlich ist.

ASP.NET ersetzt das lineare Verarbeitungsmodell von ASP, indem das Verhalten eines ereignisgesteuerten Modells emuliert wird. Das ASP.NET-Seitengerüst stellt die Zuordnungen eines Ereignisses zu einem Ereignishandler implizit her. Mit dem Seitenframework kann eine Benutzeroberfläche, die auf Benutzeraktionen reagiert, einfach erstellt werden. Ausführliche Informationen über die Erstellung und Verwendung von Ereignissen und Ereignishandlern finden Sie unter Serverereignisbehandlung in Web Forms-Seiten.

Außerdem erleichtert dieses Gerüst die Implementierung der Seiten- und die Steuerelementstatusverwaltung. Weitere Informationen über die Zustandsverwaltung finden Sie unter Web Forms-Statusverwaltung.

Beispielsweise können Sie mit ASP.NET Ereignishandler im Servercode für Ereignisse einrichten, die vom Browser übergeben werden. Angenommen, der Benutzer interagiert mit einer Web Forms-Seite, die ein Schaltflächen-Serversteuerelement enthält. Der Benutzer klickt auf das Schaltflächensteuerelement, und ein Ereignis wird ausgelöst, das über eine HTTP-Sendung an den Server übertragen wird, wo das ASP.NET-Seitengerüst die gesendeten Informationen interpretiert und dem ausgelösten Ereignis einen entsprechenden Ereignishandler zuordnet. Bei diesem Ereignishandler kann es sich um einen Standardhandler von ASP.NET oder um eine benutzerdefinierte Implementierung handeln. Das Gerüst ruft den entsprechenden Ereignishandler als Bestandteil der normalen Verarbeitung automatisch für die Schaltfläche auf. Aus diesem Grund ist es nicht mehr erforderlich, ereignisähnliches Verhalten in einem linearen Verarbeitungsmodell explizit zu entwerfen. Weitere Informationen über die Behandlung von Web Forms-Ereignissen finden Sie unter Ereignismodell für ASP.NET-Serversteuerelemente.

Phasen der Web Forms-Verarbeitung

Das ASP.NET-Seitengerüst verarbeitet Web Forms-Seiten in unterschiedlichen Phasen. Während jeder Phase in der Web Forms-Verarbeitung können Ereignisse ausgelöst werden, und ein dem Ereignis entsprechender Ereignishandler wird ausgeführt. Diese Methoden enthalten Einstiegspunkte – Hooks – mit denen Sie den Inhalt der Web Forms-Seite aktualisieren können.

Die folgende Tabelle enthält die häufigsten Phasen der Seitenverarbeitung, der ausgelösten Ereignisse und der typischen Verwendungsart in jeder Phase. Diese Phasen werden wiederholt, sobald das Formular angefordert oder gesendet wird. Mit der Page.IsPostBack-Eigenschaft können Sie testen, ob die Seite zum ersten Mal verarbeitet wird.

**Hinweis **Es gibt noch weitere Phasen in der Web Forms-Seitenverarbeitung, die nicht in der folgenden Tabelle enthalten sind. Diese werden jedoch für die meisten Seitenverarbeitungsszenarien nicht verwendet. Stattdessen werden sie primär von Serversteuerelementen auf der Web Forms-Seite verwendet, um sich selbst zu initialisieren und darzustellen. Wenn Sie eigene ASP.NET-Serversteuerelemente schreiben möchten, müssen Sie ausreichende Kenntnisse über diese Phasen haben. Weitere Informationen über alle Phasen bei der Seitenverarbeitung finden Sie unter Entwickeln von ASP.NET-Serversteuerelementen.

Phase	Bedeutung	Typische Verwendung
Initialisierung des ASP.NET-Seitengerüsts	Das Page_Init-Ereignis der Seite wird ausgelöst, und der Anzeigestatus der Seite und des Steuerelements wird wiederhergestellt.	Während dieses Ereignisses stellt das ASP.NET-Seitengerüst die Steuerelementeigenschaften und die Rücksendedaten wieder her.
Initialisierung des Benutzercodes	Das Page_Load-Ereignis wird ausgelöst.	Liest zuvor gespeicherte Werte und stellt sie wieder her: Prüfen Sie mit der Page.IsPostBack-Eigenschaft, ob die Seite zum ersten Mal verarbeitet wird. Wenn die Seite zum ersten Mal verarbeitet wird, führen Sie eine erste Datenbindung aus. Stellen Sie andernfalls die Steuerelementwerte wieder her. Lesen und Aktualisieren Sie die Steuerelementeigenschaften.
Überprüfung	Die Validate-Methode aller Webserver-Validatorsteuerelemente wird aufgerufen, um die angegebene Überprüfung des Steuerelements auszuführen.	(In dieser Phase ist keine Benutzerverknüpfung vorhanden. Das Ergebnis der Überprüfung kann in einem Ereignishandler überprüft werden.)
Ereignisbehandlung	Wenn die Seite aufgrund eines Formularereignisses aufgerufen wurde, wird in dieser Phase der entsprechende Ereignishandler in der Seite aufgerufen.	Führen Sie die anwendungsspezifische Verarbeitung aus: Behandeln Sie das ausgelöste Ereignis. Hinweis Ereignisse werden nicht in einer bestimmten Reihenfolge ausgelöst, außer dass im Cache gespeicherte Steuerelementereignisse, wie von der AutoPostBack-Eigenschaft angegeben, immer vor dem Senden des Ereignisses verarbeitet werden. Wenn die Seite Arten der Überprüfung für ASP.NET-Serversteuerelemente enthält, überprüfen Sie die IsValid-Eigenschaft für die Seite und für einzelne Überprüfungssteuerelemente. Speichern Sie den Status der Seitenvariablen, die Sie selbst verwalten, manuell. Überprüfen Sie die IsValid-Eigenschaft der Seite oder einzelner Überprüfungssteuerelemente. Speichern Sie den Status der Steuerelemente, die der Seite dynamisch hinzugefügt wurden, manuell.
Aufräumen	Das Page_Unload-Ereignis wird aufgerufen, weil die Seite die Darstellung beendet hat und nun verworfen werden kann.	Führen Sie abschließende Aufräumaufgaben aus: Schließen Sie die Dateien. Schließen Sie die Datenbankverbindungen. Verwerfen Sie die Objekte. Hinweis Es ist wichtig, dass teure Ressourcen wie Datenbankverbindungen ausdrücklich geschlossen werden. Andernfalls bleiben sie bis zur nächsten Garbage Collection bestehen. Auf einem stark ausgelasteten Server können viele offene Ressourcen die Leistung nachteilig beeinflussen.

Siehe auch

Share via