Ausführliche Diskussion über die ASP.NET-Webseitenanwendung

1. Grundlegende Einführung in Serverskripte

Sehen wir uns zunächst die grundlegenden Ausführungsmethoden von Webserverseiten an:

1. Der Client sendet eine Anfrage an den Server, indem er die Adresse in die Adressleiste des Browsers eingibt

. 2. Nachdem der Server die Anfrage erhalten hat, Es sendet es an Die entsprechende serverseitige Seite (d. h. ein Skript) wird ausgeführt. Das Skript generiert eine Antwort vom Client und sendet sie an den Client zurück.

3. Der Client-Browser empfängt die Antwort vom Server und analysiert sie HTML und stellt dem Benutzer die grafische Webseite dar. Für

die Interaktion zwischen dem Server und dem Client werden normalerweise die folgenden Hauptmethoden verwendet:

1. Formular: Dies ist die wichtigste Methode, um Benutzereingaben zu erhalten. Die Übermittlung des Formulars sendet die Daten zur Verarbeitung an den Server.

2. QueryString: Durch Hinzufügen von Parametern nach der URL werden die Parameter an den Server übertragen.

3. Cookies: Dies ist Eine spezielle Methode, die normalerweise zur Bestätigung der Benutzeridentität verwendet wird

. 2. ASP.Net-Einführung

Herkömmliche Serverskriptsprachen wie ASP, JSP usw. schreiben Serverskripte auf die gleiche Weise. Sie betten alle interpretierte oder kompilierte und ausgeführte Codes ein in HTML, und die Serverplattform führt diese Codes aus, um HTML für ähnliche Skripte und Seiten zu generieren. Der Lebenszyklus von Servlet ist eigentlich sehr einfach, das heißt, der gesamte Code wird natürlich von Anfang bis Ende ausgeführt Java kann komplexeren Code schreiben, unterscheidet sich jedoch aus struktureller Sicht nicht von JSP.

Das Aufkommen von ASP.Net brach mit dieser Tradition; ASP.Net übernahm die CodeBehind-Technologie und serverseitige Steuerungen, fügte das Konzept serverseitiger Ereignisse hinzu, änderte das Schreibmodell der Skriptsprache und näherte sich der Windows-Programmierung an, wodurch die Webprogrammierung einfacher wurde. , intuitiv; aber wir müssen sehen, dass ASP.Net selbst das Grundmodell der Webprogrammierung nicht ändert, sondern lediglich einige Details kapselt und einige benutzerfreundliche Funktionen bereitstellt, wodurch der Code bis zu einem gewissen Grad einfacher zu schreiben und zu warten ist Umfang, was die Art und Weise der serverseitigen Ausführung erschwert. Dies ist das Hauptthema, das wir heute diskutieren werden: der Lebenszyklus der ASP.Net-Webseite.

3. ASP.Net-Anforderungsverarbeitungsmodus

Wir sagen, dass die ASP.Net-Webseite nicht vom Webprogrammierungsmodus abweicht, sodass sie weiterhin im Modus „Anfrage -> Anfrage empfangen -> Anfrage verarbeiten -> Antwort senden“ funktioniert mit dem Client löst eine neue Anfrage aus, sodass der Lebenszyklus einer Webseite auf einer Anfrage basiert.

Wenn IIS eine Anfrage vom Client empfängt, übergibt es die Anfrage zur Verarbeitung an den aspnet_wp-Prozess. Dieser Prozess prüft, ob die angeforderte Anwendungsdomäne vorhanden ist, und erstellt dann eine HTTP-Laufzeit (. HttpRuntime) zur Verarbeitung von Anforderungen verwendet, stellt diese Laufzeit „eine Reihe von ASP.NET-Laufzeitdiensten für die aktuelle Anwendung bereit“ (von MSDN).

Wenn HttpRuntime Anforderungen verarbeitet, verwaltet es eine Reihe von Anwendungsinstanzen, dh Instanzen der globalen Klasse der Anwendung (global.asax). Diese Instanzen werden in einem Anwendungspool gespeichert (eigentlich). Der Anwendungspool wird verwaltet (von einer anderen Klasse ist HttpRuntime nur ein einfacher Aufruf.) Jedes Mal, wenn eine Anfrage eingeht, ruft HttpRuntime eine inaktive Instanz ab, um die Anfrage zu verarbeiten Gehen Sie zurück zum Pool: „Eine Instanz wird während ihrer Lebensdauer zur Verarbeitung mehrerer Anforderungen verwendet, kann jedoch jeweils nur eine Anforderung verarbeiten.“ (Auszug aus MSDN)

Wenn die Anwendungsinstanz die Anforderung verarbeitet, wird eine Instanz von erstellt die Anforderungsseitenklasse und führen Sie ihre ProcessRequest-Methode aus, um die Anforderung zu verarbeiten. Diese Methode ist der Beginn des Webseitenlebenszyklus.

4. Aspx-Seite und CodeBehind

Bevor wir uns mit dem Lebenszyklus der Seite befassen, besprechen wir zunächst einige Beziehungen zwischen Aspx und CodeBehind.

<%@ Page language="c#" Codebehind="WebForm.aspx.cs" Inherits="MyNamespace.WebForm" %>

Ich glaube, dass Freunde, die CodeBehind-Technologie verwendet haben, mit diesem Satz oben in ASPX gut vertraut sein sollten Analysieren Sie es einzeln:

Seitensprache = „c#“ Selbstverständlich gibt

Codebehind = „WebForm.aspx.cs“ an. Dieser Satz gibt die gebundene Codedatei an.

Inherits = „MyNamespace.WebForm“ Dieser Satz ist sehr wichtig. Er stellt den Klassennamen dar Von der Seite geerbt, die die Klasse in der Codedatei von CodeBehind ist. Diese Klasse muss von System.Web.WebControls.Page abgeleitet werden.

Aus dem Obigen können wir analysieren, dass die Klasse in CodeBehind tatsächlich die Basis der Seite ist (ASPX). An dieser Stelle möchten einige Freunde vielleicht fragen, ob Sie beim Schreiben von ASPX Code oder Serversteuerelemente genau nach der ASP-Methode einbetten. ?

Dieses Problem ist eigentlich nicht kompliziert. Freunde, die ASP.Net-Programmierung verwenden, können auf Ihre Systemfestplatte gehen: WINDOWSMicrosoft.NETFramework<Versionsnummer>Temporäre ASP.NET-Dateien und unter Alle temporären Dateien von ASP ablegen .Net-Anwendungen, die auf diesem Computer vorhanden sind, sind der Name der Anwendung und gehen dann zwei Ebenen nach unten (um die Eindeutigkeit sicherzustellen, generiert ASP.Net automatisch zwei Ebenen von Unterverzeichnissen und das Unterverzeichnis Der Name ist zufällig), und dann werden wir feststellen, dass es viele Linkbibliotheken gibt, die den Dateien „yfy1gjhc.dll“, „xeunj5u3.dll“ und Quellen wie „komee-bp.0.cs“ und „9falckav.0.cs“ ähneln Tatsächlich ist dies das Ergebnis der dynamischen Kompilierung von ASPX durch ASP.Net. Wenn wir diese Quelldateien öffnen, finden wir:

öffentliche Klasse WebForm_aspx: MyNamespace.WebForm,

System.Web.SessionState.IRequiresSessionState , ASPX Es ist eine Unterklasse der Code-Bindungsklasse. Ihr Name ist der ASPX-Dateiname plus das Suffix „_aspx“. Durch das Studium dieser Codes können wir feststellen, dass tatsächlich alle in aspx definierten Serversteuerelemente in diesen Codes generiert werden Wenn diese Codes dann dynamisch generiert werden, wird der ursprünglich in ASPX eingebettete Code an die entsprechende Stelle geschrieben.

Wenn eine Seite zum ersten Mal besucht wird, verwendet die HTTP-Laufzeit einen Codegenerator, um die ASPX-Datei zu analysieren, Quellcode zu generieren und zu kompilieren. Bei nachfolgenden Besuchen wird die kompilierte DLL daher direkt aufgerufen ist sehr langsam.

Nachdem wir dieses Problem erklärt haben, schauen wir uns ein anderes Problem an. Wenn wir Codebindung verwenden, ziehen Sie ein Steuerelement auf die Designseite und wechseln dann zur Codeansicht. Sie können das Steuerelement direkt in Page_Load verwenden. Warum kann das Steuerelement in der Unterklasse verwendet werden? Wie wäre es mit der direkten Verwendung?

können wir

feststellen, dass immer dann, wenn wir VS.Net zum Ziehen eines Steuerelements auf die Seite verwenden, eine Anweisung ähnlich dieser zur Codebindungsdatei hinzugefügt wird:

protected System.Web.WebControls.Button Button1;

Das Feld ist als geschützt zu deklarieren und der Name stimmt mit der ID des Steuerelements in ASPX überein. Wenn Sie sorgfältig darüber nachdenken, wird dieses Problem gelöst. Wir haben bereits erwähnt, dass der Quellcode von ASPX vom Generator dynamisch generiert und kompiliert wird. Beim Generieren prüft er, ob die übergeordnete Klasse dieses Steuerelement deklariert hat. Es wird ein Code ähnlich dem folgenden hinzugefügt:

this.DataGrid1 = __ctrl;

This __ctrl ist die Variable, die das Steuerelement generiert. Zu diesem Zeitpunkt weist es die Referenz des Steuerelements der entsprechenden Variablen in der übergeordneten Klasse zu Die Deklaration der übergeordneten Klasse muss geschützt sein (eigentlich kann sie auch öffentlich sein), da sichergestellt werden muss, dass Unterklassen sie aufrufen können.

Wenn dann Page_Load ausgeführt wird, können wir dieses Feld verwenden, um auf das entsprechende Steuerelement zuzugreifen, da der Deklaration der übergeordneten Klasse ein Wert zugewiesen wurde im Konstruktor in der angegebenen Datei verursacht einen Null-Referenz-Ausnahmefehler. Da der Konstruktor zuerst ausgeführt wird, hat die Initialisierung der Unterklasse noch nicht begonnen, sodass die Felder in der übergeordneten Klasse Nullwerte haben. Wir werden später darauf eingehen wenn eine Klasse initialisiert wird.

5. Seitenlebenszyklus

Zurück zum im dritten Titel erwähnten Inhalt: Wir haben über die Instanz von HttpApplication gesprochen, die die Anfrage empfängt und eine Instanz der Seitenklasse erstellt. Tatsächlich handelt es sich bei dieser Instanz um eine Instanz der dynamisch kompilierten ASPX-Klasse. Im vorherigen Titel haben wir erfahren, dass ASPX tatsächlich eine Unterklasse der Klasse in der Codebindung ist und daher alle geschützten Methoden erbt.

Schauen wir uns nun den Code der von VS.Net automatisch generierten CodeBehind-Klasse an, um unsere Diskussion über den Seitenlebenszyklus zu beginnen:

#region Web Form Designer generierter Code

override protected void OnInit(EventArgs e)
{
//
// CODEGEN: Dieser Aufruf wird vom ASP.NET Web Forms-Designer benötigt.
//
InitializeComponent();
base.OnInit(e);
}

/// <Zusammenfassung>
/// Designer unterstützt erforderliche Methoden – verwenden Sie zum Ändern keinen Code-Editor
/// Der Inhalt dieser Methode.
/// </summary>

private void InitializeComponent()
{
this.DataGrid1.ItemDataBound += new System.Web.UI.WebControls.DataGridItemEventHandler(this.DataGrid1_ItemDataBound);

this.Load += new System.EventHandler(this.Page_Load);
}

#endregion

Dies ist der mit VS.Net generierte Code. Es gibt zwei Methoden darin, eine ist OnInit und die andere ist InitializeComponent Beginn der Seiteninitialisierung. In InitializeComponent sehen wir die Ereignisdeklaration des Steuerelements und die Load-Deklaration der Seite.

Das Folgende ist ein Auszug aus MSDN und eine Sequenztabelle der Seitenlebenszyklusmethoden und der Ereignisauslösung:

„Jedes Mal, wenn eine ASP.NET-Seite angefordert wird, lädt der Server eine ASP.NET-Seite und entlädt die Seite, wenn die Anforderung abgeschlossen ist.“ Die Seite und die darin enthaltenen Serversteuerelemente sind für die Ausführung der Anfrage und die Darstellung des HTML-Codes an den Client verantwortlich. Obwohl die Kommunikation zwischen dem Client und dem Server zustandslos und intermittierend ist, muss sie vom Client als kontinuierlicher Prozess wahrgenommen werden.

„Diese Illusion der Kontinuität wird durch das ASP.NET-Seitenframework, die Seite und ihre Steuerelemente implementiert. Nach einem Postback muss das Verhalten des Steuerelements so aussehen, als würde es dort beginnen, wo die letzte Webanforderung endete. Frameworks können die Verwaltung des Ausführungsstatus relativ gestalten Einfach, aber um Kontinuitätseffekte zu erzielen, müssen Kontrollentwickler die Ausführungsreihenfolge von Kontrollen kennen und verstehen, welche Informationen in jeder Phase des Kontrolllebenszyklus verwendet werden können Beispielsweise kann ein Steuerelement sein übergeordnetes Element nicht aufrufen, bis die Steuerelementstruktur auf der Seite gefüllt ist. Die folgende Tabelle bietet einen allgemeinen Überblick über die Phasen im Steuerelementlebenszyklus. Klicken Sie in die Tabelle. Link."

Aus dieser Tabelle können wir die aufgerufenen Methoden und die Auslösezeit einer Seite vom Laden bis zum Entladen deutlich erkennen. Als nächstes werden wir sie eingehend analysieren.

Nach einem Blick auf die obige Tabelle fragen sich aufmerksame Freunde vielleicht: Da OnInit der Beginn des Seitenlebenszyklus ist und wir in der vorherigen Vorlesung über die Erstellung von Steuerelementen in Unterklassen gesprochen haben, verwenden wir hier tatsächlich die in der übergeordneten Klasse deklarierten Felder der InitializeComponent-Methode kann bereits verwendet werden. Bedeutet das, dass die Unterklasse vorher initialisiert wurde?

Im dritten Titel haben wir erwähnt, dass die ProcessRequest der Seitenklasse im eigentlichen Sinne der Beginn des Seitendeklarationszyklus ist. Diese Methode wird von HttpApplication aufgerufen (die aufrufende Methode ist komplizierter, und ich werde die Möglichkeit haben, eine zu schreiben Zur Erläuterung gibt es einen separaten Artikel). WebControls.TemplateControl (es ist die Seiten- und Benutzersteuerung. In der Basisklasse wird eine virtuelle Methode „FrameworkInitialize“ definiert), und dann wird diese Methode zuerst im ProcessRequest der Seite aufgerufen. Wir haben Spuren dieser Methode im ASPX-Quellcode gefunden Alle vom Generator generierten Steuerelemente werden in dieser Methode initialisiert und zu diesem Zeitpunkt wird der Steuerbaum der Seite generiert.

Das nächste ist einfach: Lassen Sie uns nach und nach jedes Element des Seitenlebenszyklus analysieren:

1. Initialisierung

Die Initialisierung entspricht dem Init-Ereignis und der OnInit-Methode der Seite.

Wenn Sie umschreiben möchten, empfiehlt MSDN, die OnInti-Methode zu überladen, anstatt einen Proxy für das Init-Ereignis hinzuzufügen. Es gibt einen Unterschied zwischen den beiden. Ersteres kann die Reihenfolge steuern, in der die OnInit-Methode der übergeordneten Klasse aufgerufen wird Letzteres kann nur in der übergeordneten Klasse verwendet werden. Wird nach OnInit ausgeführt (tatsächlich in OnInit aufgerufen).

2. Ansichtsstatus laden

Dies ist eine wichtigere Methode. Wir wissen, dass jede Anforderung tatsächlich von einer anderen Seitenklasseninstanz verarbeitet wird. Um den Status zwischen zwei Anforderungen sicherzustellen.

Die LoadViewState-Methode ruft den letzten Status von ViewState ab und durchläuft mithilfe der Rekursion den gesamten Baum entsprechend der Struktur des Steuerelementbaums auf der Seite, um den entsprechenden Status für jedes Steuerelement wiederherzustellen.

3. Postback-Daten verarbeiten

Mit dieser Methode wird überprüft, ob sich der Status der vom Client zurückgesendeten Steuerdaten geändert hat. Prototyp der Methode:

public virtual bool LoadPostData(string postDataKey, NameValueCollection postCollection)

postDataKey ist das Schlüsselwort, das das Steuerelement identifiziert (d. h. der Schlüssel in postCollection ist eine Sammlung, die Postback-Daten enthält). Die Rückgabe gibt an, ob sich die gesendeten Daten geändert haben. Wenn ja, wird True zurückgegeben. „LoadPostData gibt True zurück, wenn sich der Steuerelementstatus aufgrund des Postbacks ändert. Andernfalls wird False zurückgegeben. Das Seitenframework verfolgt alle Steuerelemente, die True zurückgeben, und ruft RaisePostDataChangedEvent für diese Steuerelemente auf „(Auszug aus MSDN)

Diese Methode ist in System.Web.WebControls.Control definiert und ist auch die Methode, die alle benutzerdefinierten Steuerelemente verarbeiten müssen, die Ereignisse verarbeiten müssen. Für die Seite, die wir heute besprechen, können Sie sie belassen allein.

4. Das Laden

entspricht dem Load-Ereignis und der OnLoad-Methode. Ich glaube, die meisten Freunde werden mit der von VS.Net generierten Page_Load-Methode vertraut sein Wenn ein Ereignis ausgelöst wird, wird auch die Page_Load-Methode ausgeführt. Dies ist meiner Meinung nach auch der erste Schritt für die meisten Menschen, ASP.Net zu verstehen.

Die Page_Load-Methode reagiert auf das Load-Ereignis, das in der System.Web.WebControl.Control-Klasse definiert ist (diese Klasse ist der Vorfahre von Page und allen Serversteuerelementen) und in der OnLoad-Methode ausgelöst wird.

Viele Leute sind möglicherweise auf so etwas gestoßen. Sie haben eine PageBase-Klasse geschrieben und dann die Benutzerinformationen in Page_Load überprüft. Es stellte sich heraus, dass Page_Load der Unterklassenseite immer zuerst ausgeführt wird Dieses Mal bleiben möglicherweise einige Informationen übrig. Aus Sicherheitsgründen kann der Benutzer die Page_Load-Methode in der Unterklasse ausführen, ohne authentifiziert zu sein.

Der Grund für dieses Problem ist sehr einfach: Die Page_Load-Methode wird zum Load-Ereignis in OnInit hinzugefügt, und die OnInit-Methode der Unterklasse fügt zuerst das Load-Ereignis hinzu und ruft dann base.OnInit auf, was dazu führt, dass die Unterklasse zuerst Page_Load hinzugefügt wird , dann zuerst ausgeführt.

Es gibt auch zwei Methoden, um dieses Problem zu lösen:

1) Überladen Sie die OnLoad-Methode in PageBase, authentifizieren Sie dann den Benutzer in OnLoad und rufen Sie dann base.OnLoad auf, da das Load-Ereignis in OnLoad ausgelöst wird Stellen Sie sicher, dass Sie den Benutzer authentifizieren, bevor Sie das Load-Ereignis auslösen.

2) Rufen Sie zuerst base.OnInit in der OnInit-Methode der Unterklasse auf, um sicherzustellen, dass die übergeordnete Klasse zuerst Page_Load ausführt.

5. Postback-Änderungsbenachrichtigung senden.

Diese Methode entspricht der Verarbeitung von Postback-Daten in Schritt 3. Wenn die Postback-Daten verarbeitet werden , True wird zurückgegeben. Das Seitenframework ruft diese Methode auf, um Datenänderungsereignisse auszulösen. Daher muss das Postback-Datenänderungsereignis des benutzerdefinierten Steuerelements in dieser Methode ausgelöst werden.

Ebenso ist diese Methode für Page nicht sehr nützlich. Natürlich können Sie auch Datenänderungsereignisse auf Basis von Page definieren.

6. Postback-Ereignisse verarbeiten

Bei dieser Methode werden die meisten Serversteuerereignisse ausgelöst, wenn die Anforderung Informationen über Steuerereignisauslöser enthält (Ereignisse von Serversteuerelementen sind ein weiteres Thema, ich werde in naher Zukunft einen weiteren Artikel darüber schreiben), die Seitensteuerung Die RaisePostBackEvent-Methode des entsprechenden Steuerelements wird aufgerufen, um das serverseitige Ereignis auszulösen.

Hier kommt eine weitere häufige Frage:

Internetnutzer fragen oft, warum sich die übermittelten Daten nach der Änderung nicht geändert haben.

In den meisten Fällen verstehen sie den Auslöseprozess von Serverereignissen nicht. Wir können sehen, dass das Serverereignis nach dem Laden der Seite ausgelöst wird. Das heißt, die Seite führt zuerst Page_Load und dann das Klickereignis der Schaltfläche aus (hier ist die Schaltfläche als Beispiel) und verarbeitet dann die Änderungen im Schaltflächenereignis Dies stellt ein Problem dar. Page_Load wird immer vor dem Schaltflächenereignis ausgeführt, was bedeutet, dass der Datenbindungscode in Page_Load zuerst ausgeführt wird und die Originaldaten dem Steuerelement zugewiesen werden Wenn das Schaltflächenereignis ausgeführt wird, werden tatsächlich die Originaldaten abgerufen, sodass die Aktualisierung natürlich keine Auswirkungen hat.

Es ist auch sehr einfach, dieses Problem zu ändern. Ein vernünftigerer Ansatz besteht darin, den Datenbindungscode in eine Methode zu schreiben. Nehmen wir an, es handelt sich um BindData:

private void BindData().
{
//Daten binden
}

Ändern Sie dann PageLoad:

private void Page_Load( object sender,EventArgs e)
{
if(!IsPostBack)
{
BindData(); //Daten binden, wenn die Seite zum ersten Mal aufgerufen wird}
}

Zum Schluss im Button-Event:

private Button1_Click( object sender,EventArgs e )
{
//Daten aktualisierenBindData();//Daten erneut binden
}

7.

Die Verarbeitung der endgültigen Anforderung für das Vor-Rendering wird in eine an den Server zurückgesendete Antwort umgewandelt. In der Vor-Rendering-Phase werden die vor dem endgültigen Rendern vorgenommenen Statusänderungen durchgeführt, da wir vor dem Rendern ein Steuerelement ausführen müssen Generieren Sie HTML basierend auf seinen Eigenschaften, z. B. dem Style-Attribut, das das typischste Beispiel ist. Vor dem Vorrendern können wir den Stil eines Steuerelements speichern und anzeigen Stilinformationen als Rendering-Stufe.

8. Speichern Sie den Status.

Wir haben oft erwähnt, dass verschiedene Instanzen zwischen den Anforderungen verarbeitet werden. Daher müssen wir den Status dieser Seite speichern .

9. Zu

diesem Zeitpunkt ist die Anforderungsverarbeitung der Seite im Wesentlichen abgeschlossen. In der Render-Methode wird der Kontrollbaum der gesamten Seite rekursiv aufgerufen, die Render-Methode wird nacheinander aufgerufen und der entsprechende HTML-Code wird geschrieben in den endgültigen Antwortstrom.

10. Entsorgung

ist eigentlich die Dispose-Methode. In dieser Phase werden belegte Ressourcen, wie z. B. Datenbankverbindungen, freigegeben.

11.

Am Ende des Entladens führt die Seite die OnUnLoad-Methode aus, um das UnLoad-Ereignis auszulösen, das die endgültige Verarbeitung vor der Zerstörung des Seitenobjekts übernimmt. Tatsächlich stellt ASP.Net dieses Ereignis nur aus Designgründen bereit der Ressourcen wird in der Dispose-Methode abgeschlossen. Daher ist diese Methode unbrauchbar geworden.

Wir haben den Lebenszyklus der Seite kurz vorgestellt und die Verarbeitung serverseitiger Ereignisse weniger ausführlich erläutert. Heute möchte ich vor allem, dass jeder den Zyklus der Seitenausführung versteht der Serverkontrollen in der Zukunft zu diskutieren.

Diese Inhalte sind einige meiner Erfahrungen bei der Seitenrecherche, als ich ASP.Net lernte. Die spezifischen Details werden nicht im Detail besprochen, aber ich habe einige häufige Fehler und Fehler von Anfängern genannt Ich hoffe, es kann allen Inspiration bringen.