ASP.NET 웹 페이지 애플리케이션 심층 토론

1. 서버 스크립트 기본 소개

먼저 웹 서버 페이지의 기본 실행 방법을 살펴보겠습니다.

1. 클라이언트는 브라우저의 주소 표시줄에 주소를 입력하여 서버에 요청을 보냅니다

. 2. 서버가 요청을 받은 후, 해당 서버측 페이지(즉, 스크립트)가 실행됩니다. 스크립트는 클라이언트로부터 응답을 생성하여 클라이언트로 다시 보냅니다.

3. 클라이언트 브라우저는 서버로부터 응답을 받아 구문 분석합니다. HTML을 사용하여 사용자에게 그래픽 웹 페이지를 제공합니다.

서버와 클라이언트 간의 상호 작용에는 일반적으로 다음과 같은 주요 방법이 사용됩니다.

1. 형식: 이것은 사용자 입력을 얻는 데 사용되는 가장 중요한 방법입니다. Form을 제출하면 처리를 위해 데이터가 서버로 전송됩니다.

2. QueryString: Url 뒤에 매개변수를 추가하면 이 메서드가 실제로 Get 메서드와 동일합니다

. 일반적으로 사용자의 신원을 확인하는 데 사용되는 특별한 방법

2. ASP.Net 소개

ASP, JSP 등과 같은 전통적인 서버 스크립트 언어는 모두 해석되거나 컴파일되고 실행되는 코드를 포함합니다. 그리고 서버 플랫폼은 유사한 스크립트, 페이지에 대해 이러한 코드를 실행합니다. 서블릿의 수명주기는 실제로 매우 간단합니다. 즉, 모든 코드는 처음부터 끝까지 실행됩니다. Java는 더 복잡한 코드를 작성할 수 있지만 구조적인 관점에서는 JSP와 다르지 않습니다.

ASP.Net의 출현으로 이러한 전통이 깨졌습니다. ASP.Net은 CodeBehind 기술과 서버측 컨트롤을 채택하고, 서버측 이벤트 개념을 추가했으며, 스크립팅 언어 작성 모델을 변경하고, Window 프로그래밍에 더 가까워지면서 웹 프로그래밍이 더 쉬워졌습니다. , 직관적이지만 ASP.Net 자체는 웹 프로그래밍의 기본 모델을 변경하지 않고 단지 일부 세부 사항을 캡슐화하고 사용하기 쉬운 기능을 제공하여 특정 코드를 더 쉽게 작성하고 유지 관리할 수 있다는 점을 알아야 합니다. 범위는 서버 측 실행 방식을 복잡하게 만듭니다. 이것이 오늘 논의할 주요 주제인 ASP.Net 웹 페이지의 수명 주기입니다.

3. ASP.Net 요청 처리 모드

ASP.Net의 웹 페이지는 웹 프로그래밍 모드에서 벗어나지 않으므로 여전히 요청->요청 수신->요청 처리->응답 전송 모드로 작동한다고 합니다. 클라이언트를 사용하면 새 요청이 트리거되므로 웹 페이지의 수명 주기는 하나의 요청을 기반으로 합니다.

IIS는 클라이언트로부터 요청을 받으면 처리를 위해 요청을 aspnet_wp 프로세스로 전달합니다. 이 프로세스는 요청한 응용 프로그램 도메인이 존재하는지 확인한 다음 Http 런타임( HttpRuntime) 요청을 처리하기 위해 이 런타임은 "현재 응용 프로그램에 대한 ASP.NET 런타임 서비스 집합을 제공"합니다(MSDN 참조).

HttpRuntime은 요청을 처리할 때 일련의 애플리케이션 인스턴스, 즉 애플리케이션의 글로벌 클래스(global.asax) 인스턴스를 유지 관리합니다. 이러한 인스턴스는 요청이 없을 때 애플리케이션 풀에 저장됩니다(실제로 애플리케이션 풀은 유지 관리됩니다. 다른 클래스의 경우 HttpRuntime은 단순한 호출일 뿐입니다. 요청이 수신될 때마다 HttpRuntime은 요청을 처리하기 위해 유휴 인스턴스를 얻습니다. 이 인스턴스는 요청이 완료되기 전에 다른 요청을 처리하지 않습니다. 풀로 돌아가서 "인스턴스는 수명 동안 여러 요청을 처리하는 데 사용되지만 한 번에 하나의 요청만 처리할 수 있습니다."(MSDN에서 발췌)

응용 프로그램 인스턴스가 요청을 처리하면 다음 인스턴스가 생성됩니다. 요청 페이지 클래스를 실행하고 해당 ProcessRequest 메서드를 실행하여 요청을 처리합니다. 이 메서드는 웹 페이지 수명 주기의 시작입니다.

4. Aspx 페이지 및 CodeBehind

페이지의 수명 주기를 살펴보기 전에 먼저 Aspx와 CodeBehind 간의 관계에 대해 몇 가지 살펴보겠습니다.

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

CodeBehind 기술을 사용해본 친구들이라면 ASPX 상단에 있는 이 문장이 아주 익숙할 거라 믿습니다. 하나씩 분석해 보세요.

페이지 언어="c#" 말할 필요도 없이

Codebehind="WebForm.aspx.cs" 이 문장은 바인딩된 코드 파일을 나타냅니다.

Inherits="MyNamespace.WebForm" 이 문장은 클래스 이름을 나타냅니다. CodeBehind의 코드 파일에 있는 클래스인 페이지에 의해 상속됩니다. 이 클래스는 System.Web.WebControls.Page에서 파생되어야 합니다.

위에서 우리는 실제로 CodeBehind의 클래스가 페이지의 기초임을 분석할 수 있습니다. (ASPX).이 시점에서 일부 친구들은 ASPX를 작성할 때 소위 "클래스"라는 그림자가 보이지 않는지 HTML에 정확히 포함하는지 묻고 싶어할 수 있습니다. ?

이 문제는 실제로 복잡하지 않습니다. ASP.Net 프로그래밍을 사용하는 친구는 시스템 디스크: WINDOWSMicrosoft.NETFramework<버전 번호>Temporary ASP.NET Files로 이동하여 ASP의 모든 임시 파일 아래에 넣을 수 있습니다. 이 컴퓨터에 존재하는 .Net 응용 프로그램의 하위 디렉터리 이름은 응용 프로그램의 이름이고 두 수준 아래로 내려갑니다(고유성을 보장하기 위해 ASP.Net은 자동으로 두 수준의 하위 디렉터리를 생성하며 하위 디렉터리 이름은 다음과 같습니다). 무작위), 그러면 "yfy1gjhc.dll", "xeunj5u3.dll"과 유사한 링크 라이브러리와 "komee-bp.0.cs" 및 "9falckav.0.cs" 파일과 같은 소스가 많이 있음을 알 수 있습니다. 실제로 이는 ASP.Net에 의해 동적으로 컴파일된 ASPX의 결과입니다. 이러한 소스 파일을 열면 다음을 찾을 수 있습니다.

public class WebForm_aspx: MyNamespace.WebForm, System.Web.SessionState.IRequiresSessionState

이는 이전 설명을 확인합니다

, ASPX 코드 바인딩 클래스의 하위 클래스입니다. 이름은 ASPX 파일 이름에 "_aspx" 접미사를 더한 것입니다. 이러한 코드를 연구하면 실제로 aspx에 정의된 모든 서버 컨트롤이 이러한 코드에서 생성된다는 것을 알 수 있습니다. 그런 다음 이러한 코드가 동적으로 생성되면 원래 ASPX에 포함된 코드가 해당 위치에 기록됩니다.

페이지를 처음 방문하면 HTTP 런타임은 코드 생성기를 사용하여 ASPX 파일을 구문 분석하고 소스 코드를 생성한 후 컴파일합니다. 그런 다음 후속 방문에서는 컴파일된 dll을 직접 호출합니다. 매우 느립니다.

이 문제를 설명했으니, 또 다른 문제를 살펴보겠습니다. 코드 바인딩을 사용할 때 디자인 페이지에서 컨트롤을 드래그한 다음 코드 보기로 전환하면 컨트롤이 하위 클래스에서 생성되는데 왜 상위 클래스에서 사용할 수 있나요? 직접 사용해 보는 것은 어떨까요?

실제로 VS.Net을 사용하여 컨트롤을 페이지로 끌 때마다 다음과 유사한 명령문이 항상 코드 바인딩 파일에 추가된다는 것을 알 수 있습니다.

protected

System.Web.WebControls.Button Button1;

필드는 보호됨으로 선언하고 이름은 ASPX의 컨트롤 ID와 일치해야 합니다. 잘 생각해보면 이 문제는 해결될 것입니다. 앞서 ASPX의 소스 코드는 생성기에 의해 동적으로 생성되고 컴파일된다고 언급했습니다. 생성기는 각 서버 컨트롤을 동적으로 생성하는 코드를 생성할 때 부모 클래스가 이 컨트롤을 선언했는지 확인합니다. 다음과 유사한 코드가 추가됩니다.

this.DataGrid1 = __ctrl;

이 __ctrl은 컨트롤을 생성하는 변수입니다. 이때 컨트롤의 참조를 상위 클래스의 해당 변수에 할당합니다. 상위 클래스 선언은 하위 클래스에서 호출할 수 있도록 보장해야 하기 때문에 보호되어야 합니다(실제로 공개일 수도 있음).

그런 다음 Page_Load가 실행되면 하위 클래스의 초기화 코드에 의해 상위 클래스의 선언에 값이 할당되므로 이 필드를 사용하여 해당 컨트롤에 액세스할 수 있으므로 컨트롤을 사용하여 코드 바인딩을 커밋하지 않습니다. 지정된 파일의 생성자에 null 참조 예외 오류가 발생하면 생성자가 먼저 실행되므로 하위 클래스의 초기화가 아직 시작되지 않았으므로 상위 클래스의 필드에는 null 값이 있습니다. 클래스가 초기화될 때.

5. 페이지 수명 주기

이제 세 번째 제목에서 언급한 내용으로 돌아가서, 요청을 수신하고 페이지 클래스의 인스턴스를 생성하는 HttpApplication 인스턴스에 대해 이야기했습니다. 실제로 이 인스턴스는 동적으로 컴파일된 ASPX 클래스의 인스턴스입니다. 이전 제목에서 우리는 ASPX가 실제로 코드 바인딩에 있는 클래스의 하위 클래스이므로 모든 보호된 메서드를 상속한다는 것을 배웠습니다.

이제 페이지 수명 주기에 대한 논의를 시작하기 위해 VS.Net에서 자동으로 생성된 CodeBehind 클래스의 코드를 살펴보겠습니다.

#region 웹 양식 디자이너 생성 코드

재정의 protected void OnInit(EventArgs e)
{
//
// CODEGEN: 이 호출은 ASP.NET Web Forms 디자이너에 필요합니다.
//
초기화구성요소();
base.OnInit(e);
}

/// <요약>
/// 디자이너는 필수 메서드를 지원합니다. 코드 편집기를 사용하여 수정하지 마세요.
/// 이 메소드의 내용입니다.
/// </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

이것은 VS.Net을 사용하여 생성된 페이지에 대한 코드입니다. 여기에는 두 가지 메서드가 있습니다. 하나는 OnInit이고 다른 하나는 전자에 의해 호출됩니다. 페이지 초기화의 시작입니다.InitializeComponent에서 컨트롤의 이벤트 선언과 페이지의 Load 선언을 볼 수 있습니다.

다음은 MSDN에서 발췌한 설명과 페이지 수명 주기 방법 및 이벤트 트리거의 시퀀스 테이블입니다.

"ASP.NET 페이지가 요청될 때마다 서버는 ASP.NET 페이지를 로드하고 요청이 완료되면 페이지를 언로드합니다. 페이지와 페이지에 포함된 서버 컨트롤은 요청을 실행하고 클라이언트에 HTML을 렌더링하는 역할을 합니다. 클라이언트와 서버 간의 통신은 상태가 없고 간헐적이지만 클라이언트는 이를 연속 프로세스로 인식해야 합니다.

"이러한 연속성의 환상은 ASP.NET 페이지 프레임워크, 페이지 및 해당 컨트롤에 의해 구현됩니다. 포스트백 후에 컨트롤의 동작은 마지막 웹 요청이 끝난 위치에서 시작되는 것처럼 나타나야 합니다. 프레임워크는 상대적으로 실행 상태 관리를 만들 수 있습니다. 쉽지만 연속성 효과를 얻으려면 컨트롤 개발자는 컨트롤의 실행 순서를 알아야 합니다. 컨트롤 개발자는 컨트롤 수명 주기의 각 단계에서 컨트롤이 사용할 수 있는 정보와 보유할 수 있는 데이터를 이해해야 합니다. 예를 들어 컨트롤은 페이지의 컨트롤 트리가 채워질 때까지 해당 부모를 호출할 수 없습니다." 다음 표는 컨트롤 수명 주기의 단계에 대한 높은 수준의 개요를 제공합니다. 표를 클릭하세요. 링크."

이 표를 통해 호출된 메서드와 페이지 로드에서 언로드까지의 트리거 시간을 명확하게 확인할 수 있습니다. 다음으로 심층적으로 분석하겠습니다.

위의 표를 보고 세심한 친구들은 OnInit가 페이지 수명 주기의 시작이고 이전 강의에서 하위 클래스에서 생성되는 컨트롤에 대해 이야기했기 때문에 세심한 친구들이 물을 수 있습니다. 여기서는 실제로 부모 클래스에 선언된 초기화 구성 요소 메서드 필드를 사용합니다. 이미 사용할 수 있으므로 이보다 먼저 하위 클래스가 초기화된다는 의미입니까?

세 번째 제목에서 페이지 클래스의 ProcessRequest가 진정한 의미에서 페이지 선언 주기의 시작이라고 언급했습니다. 이 메서드는 HttpApplication에 의해 호출됩니다(호출 메서드는 더 복잡하므로 다음과 같이 작성할 기회가 있습니다. 페이지 요청 처리는 이 메서드에서 시작됩니다. .Net 클래스 라이브러리를 디컴파일하여 소스 코드를 보면 System.Web.WebControls.Page의 기본 클래스인 System.Web이 있습니다. WebControls.TemplateControl(페이지 및 사용자 컨트롤 "FrameworkInitialize" 가상 메서드가 기본 클래스에 정의되어 있음), 이 메서드는 페이지의 ProcessRequest에서 처음 호출됩니다. ASPX 소스 코드에서 이 메서드의 흔적을 찾았습니다. 모든 컨트롤은 이 메소드로 초기화되며 이때 페이지의 컨트롤 트리가 생성됩니다.

다음은 간단합니다. 페이지 수명 주기의 각 항목을 점진적으로 분석해 보겠습니다.

1. 초기화

초기화는 페이지의 Init 이벤트 및 OnInit 메서드에 해당합니다.

다시 작성하려면 Init 이벤트에 대한 프록시를 추가하는 대신 OnInti 메서드를 오버로드하는 것이 좋습니다. 전자는 상위 클래스의 OnInit 메서드가 호출되는 순서를 제어할 수 있습니다. 후자는 상위 클래스에서만 사용할 수 있습니다. OnInit 이후에 실행됩니다(실제로는 OnInit에서 호출됨).

2. 보기 상태 로드

이는 각 요청이 실제로 서로 다른 페이지 클래스 인스턴스에 의해 처리된다는 것을 알고 있습니다. 두 요청 간의 상태를 확인하기 위해 ASP.Net은 ViewState를 사용합니다.

LoadViewState 메서드는 ViewState에서 마지막 상태를 가져오고 재귀를 사용하여 페이지의 컨트롤 트리 구조에 따라 전체 트리를 순회하여 각 컨트롤에 해당 상태를 복원합니다.

3. 포스트백 데이터 처리

클라이언트가 다시 보낸 컨트롤 데이터의 상태가 변경되었는지 확인하는 방법입니다. 메소드의 프로토타입:

public virtual bool LoadPostData(string postDataKey, NameValueCollection postCollection)

postDataKey는 컨트롤을 식별하는 키워드입니다(즉, postCollection의 키는 포스트백 데이터를 포함하는 컬렉션입니다. 반환 전송된 데이터가 변경되었는지 여부, 그렇다면 True를 반환합니다. "LoadPostData는 포스트백으로 인해 컨트롤 상태가 변경되면 true를 반환하고, 그렇지 않으면 false를 반환합니다. 페이지 프레임워크는 true를 반환하는 모든 컨트롤을 추적하고 이러한 컨트롤에서 raisePostDataChangedEvent를 호출합니다. "(MSDN에서 발췌)

이 메서드는 System.Web.WebControls.Control에 정의되어 있으며, 이벤트를 처리해야 하는 모든 사용자 정의 컨트롤이 처리해야 하는 메서드이기도 합니다. 오늘 논의할 페이지의 경우 그대로 두어도 됩니다. 홀로.

4. Loading은

Load 이벤트와 OnLoad 메서드에 해당합니다. 대부분의 친구들이 이 이벤트에 익숙할 것이라고 생각합니다. VS.Net에서 생성된 페이지의 Page_Load 메서드는 모든 요청에 ​​대해 Load 이벤트에 응답하는 메서드입니다. 이벤트가 트리거되면 Page_Load 메서드도 실행됩니다. 이는 대부분의 사람들이 ASP.Net을 이해하는 첫 번째 단계이기도 합니다.

Page_Load 메서드는 System.Web.WebControl.Control 클래스(이 클래스는 Page 및 모든 서버 컨트롤의 조상임)에 정의되어 있고 OnLoad 메서드에서 트리거되는 Load 이벤트에 응답합니다.

많은 사람들이 이런 일을 겪었을 것입니다. 그들은 PageBase 클래스를 작성한 다음 Page_Load에서 사용자 정보를 확인했습니다. 확인의 성공 여부에 관계없이 항상 하위 클래스 페이지의 Page_Load가 먼저 실행되는 것으로 나타났습니다. 이번에는 보안상의 이유로 일부 정보가 남을 수 있으므로 사용자가 인증되지 않은 채 하위 클래스의 Page_Load 메서드를 실행할 수 있습니다.

이 문제가 발생하는 이유는 매우 간단합니다. OnInit의 Load 이벤트에 Page_Load 메서드가 추가되고, 하위 클래스의 OnInit 메서드가 먼저 Load 이벤트를 추가한 후 base.OnInit를 호출하여 하위 클래스에 Page_Load가 먼저 추가되기 때문입니다. , 그런 다음 먼저 실행됩니다.

이 문제를 해결하는 방법도 매우 간단합니다.

1) PageBase에서 OnLoad 메서드를 오버로드한 다음 OnLoad에서 사용자를 인증한 다음 Base.OnLoad를 호출합니다. 왜냐하면 Load 이벤트가 OnLoad에서 트리거되기 때문입니다. Load 이벤트를 실행하기 전에 사용자를 인증하세요.

2) 먼저 하위 클래스의 OnInit 메서드에서 base.OnInit를 호출하여 상위 클래스가 Page_Load를 먼저 실행하는지 확인합니다.

5.

이 메서드는 3단계의 포스트백 데이터 처리에 해당합니다

, True가 반환됩니다. 페이지 프레임워크는 데이터 변경 이벤트를 트리거하기 위해 이 메서드를 호출하므로 사용자 정의 컨트롤의 포스트백 데이터 변경 이벤트가 이 메서드에서 트리거되어야 합니다.

마찬가지로 이 방법은 Page에 그다지 유용하지 않습니다. 물론 Page를 기반으로 데이터 변경 이벤트를 정의할 수도 있습니다.

6. 포스트백 이벤트 처리

이 방법은 대부분의 서버 제어 이벤트가 트리거되는 곳입니다. 요청에 제어 이벤트 트리거에 대한 정보가 포함되어 있으면(서버 제어 이벤트는 또 다른 주제이므로 가까운 시일 내에 논의할 다른 기사를 작성하겠습니다) 해당 컨트롤의 raisePostBackEvent 메서드가 호출되어 서버측 이벤트를 트리거합니다.

또 다른 일반적인 질문이 있습니다.

네티즌들은 제출된 데이터가 수정 후에도 변경되지 않은 이유를 자주 묻습니다.

대부분의 경우 페이지 로드 후에 서버 이벤트가 트리거되는 것을 볼 수 있습니다. 즉, 페이지는 먼저 Page_Load를 실행한 다음 버튼의 클릭 이벤트를 실행합니다(여기서는 버튼의 예입니다). 많은 친구들이 Page_Load에 데이터를 바인딩한 다음 버튼 이벤트의 변경 사항을 처리합니다. 문제는 Page_Load가 항상 버튼 이벤트 전에 실행된다는 것입니다. 즉, 데이터가 변경되기 전에 Page_Load의 데이터 바인딩 코드가 먼저 실행되고 원본 데이터가 컨트롤에 할당된 다음 버튼 이벤트가 실행되면 실제로 얻어지는 것은 원본 데이터이므로 업데이트는 당연히 아무런 영향을 미치지 않습니다.

이 문제를 변경하는 것도 매우 간단합니다. 보다 합리적인 접근 방식은 데이터 바인딩 코드를 메서드에 작성하는 것입니다. BindData라고 가정하겠습니다.

private void BindData()
{
//데이터 바인딩
}

그런 다음 PageLoad를 수정합니다.

private void Page_Load( object sender,EventArgs e)
{
if(!IsPostBack)
{
BindData(); //페이지에 처음 액세스할 때 데이터 바인딩}
}

마지막으로 버튼 이벤트에서:

private Button1_Click( object sender,EventArgs e )
{
//dataBindData() 업데이트;//데이터 리바인드
}

7.

사전 렌더링에 대한 최종 요청 처리는 서버로 다시 전송되는 응답으로 변환됩니다. 사전 렌더링 단계에서는 컨트롤을 렌더링하기 전에 변경된 상태를 수행해야 합니다. 가장 일반적인 예인 Style 속성을 기반으로 HTML을 생성합니다. 사전 렌더링을 수행하면 스타일을 저장하고 Html을 표시할 수 있습니다. 스타일 정보를 렌더링 단계로 사용합니다.

8. 상태 저장

이 단계는 로드 상태를 위한 단계입니다. 요청 간에 서로 다른 인스턴스가 처리된다는 점을 여러 번 언급했기 때문에 이 단계에서는 상태를 작성하고 제어해야 합니다. .

9.

이 시점에서 페이지의 요청 처리는 기본적으로 종료됩니다. Render 메서드에서는 전체 페이지의 컨트롤 트리가 반복되고 Render 메서드가 순차적으로 호출되며 해당 Html 코드가 작성됩니다. 최종 응답 스트림으로 들어갑니다.

10. Disposal은

실제로 Dispose 메서드입니다. 이 단계에서는 데이터베이스 연결 등 점유된 리소스가 해제됩니다.

11.

언로드가 끝나면 페이지는 OnUnLoad 메서드를 실행하여 페이지 개체가 삭제되기 전에 최종 처리를 처리합니다. 실제로 ASP.Net은 일반적으로 디자인 고려 사항을 위해서만 이 이벤트를 제공합니다. Dispose 메서드에서 리소스가 완료되었으므로 이 메서드는 쓸모가 없게 되었습니다.

페이지의 수명주기에 대해 간략하게 소개하고, 서버 측 이벤트 처리에 대해 덜 심층적으로 설명했습니다. 오늘은 모두가 페이지 실행 주기를 이해하기를 바랍니다. 이벤트와 수명에 대해 좀 더 작성해 보겠습니다. 앞으로 논의할 서버 제어 문서에 대해 알아보겠습니다.

이 내용은 ASP.Net을 배울 때 페이지 조사에 대한 경험 중 일부입니다. 자세한 내용은 MSDN을 참조하십시오. 그러나 초보자가 저지르는 몇 가지 일반적인 실수를 인용했습니다. , 모든 사람에게 영감을 줄 수 있기를 바랍니다.