ASP.net 하다보면 가끔 어디부터 호출이 되는지 시점 때문에..
고생하는 경우가 많습니다.. 그래서 스크랩 했습니다.
---------------------------------------------------------'
ASP.NET 페이지 수명 주기 개요

ASP.NET 페이지가 실행되면 이 페이지는 일련의 처리 단계를 수행하는 수명 주기를 거칩니다. 이러한 주기에는 초기화, 컨트롤 인스턴스화, 상태 복원 및 관리, 이벤트 처리기 코드 실행, 렌더링 등이 포함됩니다. 원하는 결과를 얻기 위해 적절한 수명 주기 단계에서 코드를 작성할 수 있도록 페이지 수명 주기를 이해해야 합니다. 또한 사용자 지정 컨트롤을 개발하는 경우에도 컨트롤을 제대로 초기화하고, 뷰 상태 데이터로 컨트롤 속성을 채우고, 컨트롤 동작 코드를 실행하려면 페이지 수명 주기에 대해 잘 알고 있어야 합니다. 컨트롤의 수명 주기는 페이지 수명 주기를 기반으로 하지만 페이지에서는 컨트롤에 대해 ASP.NET 페이지에 허용되는 것보다 많은 이벤트를 발생시킵니다.

일반적인 페이지 수명 주기 단계

일반적으로 페이지는 다음 표에서 보여 주는 단계를 거칩니다. 페이지 수명 주기 단계뿐만 아니라 요청 전/후에 발생하지만 특정 페이지에 국한되지 않은 응용 프로그램 단계도 있습니다. 자세한 내용은 ASP.NET 응용 프로그램 수명 주기 개요을 참조하십시오.

단계 설명

페이지 요청

페이지 요청은 페이지 수명 주기가 시작되기 전에 발생합니다. 사용자가 페이지를 요청하면 ASP.NET에서는 페이지를 구문 분석하고 컴파일하여 페이지 주기를 시작할지 여부 또는 페이지를 실행하지 않고 캐시된 버전의 페이지를 응답으로 보낼 수 있는지 여부를 결정합니다.

시작

시작 단계에서는 RequestResponse 같은 페이지 속성이 설정됩니다. 이 단계에서 페이지는 요청이 다시 게시인지 아니면 새 요청인지를 확인하여 IsPostBack 속성을 설정합니다. 또한 시작 단계에서는 페이지의 UICulture 속성도 설정됩니다.

페이지 초기화

페이지 초기화 단계에서는 페이지의 컨트롤을 사용할 수 있으며 각 컨트롤의 UniqueID 속성이 설정됩니다. 또한 테마가 페이지에 적용됩니다. 현재 요청이 다시 게시인 경우에는 다시 게시 데이터가 아직 로드되지 않았고 컨트롤 속성 값이 뷰 상태의 값으로 복원되지 않았습니다.

로드

로드 단계에서는 현재 요청이 다시 게시인 경우 뷰 상태 및 컨트롤 상태에서 복구된 정보와 함께 컨트롤 속성이 로드됩니다.

유효성 검사

유효성 검사 단계에서는 모든 유효성 검사기 컨트롤의 Validate 메서드가 호출되어 각 유효성 검사기 컨트롤 및 페이지의 IsValid 속성을 설정합니다.

다시 게시 이벤트 처리

요청이 다시 게시인 경우 이벤트 처리기가 호출됩니다.

렌더링

렌더링에 앞서 페이지와 모든 컨트롤에 대한 뷰 상태가 저장됩니다. 렌더링 단계를 진행하는 동안 페이지에서 각 컨트롤에 대한 Render 메서드를 호출하여 해당 출력을 페이지 Response 속성의 OutputStream에 쓰는 텍스트 작성기를 제공합니다.

언로드

페이지가 완전히 렌더링되어 클라이언트에 전달되고 삭제할 준비가 되면 언로드가 호출됩니다. 이 단계에서는 ResponseRequest 같은 페이지 속성이 언로드되고 정리 작업이 수행됩니다.

수명 주기 이벤트

페이지의 각 수명 주기 단계 내에서 페이지는 사용자가 작성한 코드를 실행하기 위해 처리할 수 있는 이벤트를 발생시킵니다. 컨트롤 이벤트의 경우 onclick 같은 특성을 사용하여 선언적으로 또는 코드를 통해 이벤트 처리기를 이벤트에 바인딩합니다.

또한 페이지에서는 자동 이벤트 연결을 지원하므로 ASP.NET에서는 특정한 이름을 사용하는 메서드를 검색하고 지정된 이벤트가 발생하면 이러한 메서드를 자동으로 실행합니다. @ Page 지시문의 AutoEventWireup 특성이 true로 설정되거나 정의되지 않은 경우(기본적으로 true로 설정되어 있음)에는 Page_LoadPage_Init처럼 Page_event 명명 규칙을 사용하는 메서드에 페이지 이벤트가 자동으로 바인딩됩니다. 자동 이벤트 연결에 대한 자세한 내용은 ASP.NET 웹 서버 컨트롤 이벤트 모델을 참조하십시오.

다음 표에서는 일반적으로 가장 자주 사용되는 페이지 수명 주기 이벤트를 보여 줍니다. 여리 나와 있는 것보다 더 많은 이벤트가 있지만 대부분의 페이지 처리 시나리오에는 사용되지 않습니다. 대신 이러한 이벤트는 주로 ASP.NET 웹 페이지의 서버 컨트롤에서 초기화 및 렌더링을 수행하는 데 사용됩니다. 고유한 ASP.NET 서버 컨트롤을 작성하려면 이러한 각 단계에 대해 자세히 이해하고 있어야 합니다. 사용자 지정 컨트롤을 만드는 방법에 대한 자세한 내용은 사용자 지정 ASP.NET 서버 컨트롤 개발을 참조하십시오.

페이지 이벤트 일반적인 용도

PreInit

이 이벤트의 용도는 다음과 같습니다.

  • IsPostBack 속성을 검사하여 페이지가 처음으로 처리되는 것인지 여부를 확인합니다.

  • 동적 컨트롤을 만들거나 다시 만듭니다.

  • 마스터 페이지를 동적으로 설정합니다.

  • Theme 속성을 동적으로 설정합니다.

  • 프로필 속성 값을 읽거나 설정합니다.

    Note참고

    요청이 다시 게시인 경우에는 컨트롤의 값이 뷰 상태에서 아직 복원되지 않았습니다. 이 단계에서 컨트롤 속성을 설정하면 다음 이벤트에서 속성 값이 덮어쓰여질 수 있습니다.

Init

모든 컨트롤을 초기화하고 모든 스킨 설정을 적용한 후에 발생합니다. 이 이벤트를 사용하여 컨트롤 속성을 읽거나 초기화할 수 있습니다.

InitComplete

Page 개체를 통해 발생합니다. 이 이벤트를 사용하여 모든 초기화를 완료해야 할 작업을 처리할 수 있습니다.

PreLoad

이 이벤트는 Load 이벤트에 앞서 페이지나 컨트롤을 처리해야 하는 경우에 사용합니다.

Page에서 이 이벤트가 발생한 후에 해당 페이지와 모든 컨트롤에 대한 뷰 상태를 로드하고 Request 인스턴스에 포함된 모든 다시 게시된 데이터를 처리합니다.

Load

Page에서 Page에 대해 OnLoad 이벤트 메서드를 호출한 다음 자식 컨트롤 각각에 대해 동일한 과정을 되풀이합니다. 이 과정이 페이지와 모든 컨트롤을 로드할 때까지 해당 자식 컨트롤 각각에 대해 동일하게 진행됩니다.

OnLoad 이벤트 메서드를 사용하면 컨트롤의 속성을 설정하고 데이터베이스 연결을 설정할 수 있습니다.

컨트롤 이벤트

이러한 이벤트를 사용하면 Button 컨트롤의 Click 이벤트나 TextBox 컨트롤의 TextChanged 이벤트 같은 특정 컨트롤 이벤트를 처리할 수 있습니다.

Note참고

다시 게시 요청에서 페이지에 유효성 검사기 컨트롤이 포함되어 있으면 처리를 수행하기 전에 Page 및 각 유효성 검사기 컨트롤의 IsValid 속성을 확인합니다.

LoadComplete

이 이벤트는 페이지의 다른 모든 컨트롤을 로드해야 하는 작업에 대해 사용합니다.

PreRender

이 이벤트가 발생하기 전에 다음 과정이 진행됩니다.

페이지의 각 컨트롤에 대해 PreRender 이벤트가 발생합니다. 이 이벤트를 사용하여 페이지나 해당 컨트롤의 내용을 최종적으로 변경할 수 있습니다.

SaveStateComplete

이 이벤트가 발생하기 전에 페이지와 모든 컨트롤에 대해 ViewState가 저장됩니다. 이 시점에서 페이지나 컨트롤에 대한 변경 내용은 모두 무시됩니다.

이 이벤트를 사용하여 뷰 상태 저장이 필요한 작업을 수행할 수 있지만 컨트롤을 변경할 수는 없습니다.

Render

이는 이벤트가 아닙니다. 대신, 이 처리 단계에서 Page 개체가 각 컨트롤에 대해 이 메서드를 호출합니다. 모든 ASP.NET 웹 서버 컨트롤에는 브라우저에 보내는 컨트롤의 태그를 작성하는 Render 메서드가 있습니다.

사용자 지정 컨트롤을 만드는 경우 일반적으로 이 메서드를 재정의하여 컨트롤의 태그를 출력합니다. 그러나 사용자 지정 컨트롤에 표준 ASP.NET 웹 서버 컨트롤만 포함되어 있고 사용자 지정 태그는 포함되지 않은 경우 Render 메서드를 재정의할 필요가 없습니다. 자세한 내용은 사용자 지정 ASP.NET 서버 컨트롤 개발을 참조하십시오.

사용자 정의 컨트롤(.ascx 파일)에는 렌더링이 자동으로 포함되므로 코드에서 컨트롤을 명시적으로 렌더링할 필요가 없습니다.

Unload

이 이벤트는 각 컨트롤에 대해 발생한 다음 페이지에 대해 발생합니다. 컨트롤에서 이 이벤트를 사용하면 컨트롤별 데이터베이스 연결을 닫는 등 특정 컨트롤에 대한 최종 정리 작업을 수행할 수 있습니다.

페이지 자체에 대해 이 이벤트를 사용하면 열려 있는 파일 및 데이터베이스 연결을 닫거나 로깅 또는 기타 요청에 따른 작업을 마무리하는 등의 최종 정리 작업을 수행할 수 있습니다.

Note참고

언로드 단계를 수행하는 동안 페이지와 페이지 컨트롤이 렌더링되었으므로 응답 스트림을 추가로 변경할 수 없습니다. Response.Write 등의 메서드를 호출하려고 하면 페이지에서 예외가 throw됩니다.

페이지 수명 주기에 대한 추가 고려 사항

개별 ASP.NET 서버 컨트롤의 고유한 수명 주기는 페이지 수명 주기와 비슷합니다. 예를 들어, 상응하는 페이지 이벤트를 실행하는 동안 컨트롤의 InitLoad 이벤트가 발생합니다.

InitLoad가 모두 각 컨트롤에 대해 재귀적으로 발생하지만 그 발생 순서는 반대입니다. 각 자식 컨트롤에 대한 InitUnload 이벤트는 해당 컨테이너에 대한 상응하는 이벤트가 발생하기 전에 발생합니다(상향식). 그러나 컨테이너에 대한 Load 이벤트는 해당 자식 컨트롤에 대한 Load 이벤트가 발생하기 전에 발생합니다(하향식).

Button 컨트롤에 대한 Click 이벤트나 ListBox 컨트롤에 대한 SelectedIndexChanged 이벤트 같은 컨트롤의 이벤트를 처리하여 컨트롤의 모양이나 내용을 사용자 지정할 수 있습니다. 경우에 따라 컨트롤의 DataBinding 또는 DataBound 이벤트를 처리할 수도 있습니다. 자세한 내용은 각 컨트롤의 클래스 참조 항목 및 사용자 지정 ASP.NET 서버 컨트롤 개발을 참조하십시오.

클래스를 Page 클래스에서 상속하는 경우 페이지에서 발생한 이벤트를 처리할 수 있을 뿐만 아니라 페이지의 기본 클래스에서 메서드를 재정의할 수도 있습니다. 예를 들어 페이지의 InitializeCulture 메서드를 재정의하여 culture 정보를 동적으로 설정할 수 있습니다. Page_event 구문을 사용하여 이벤트 처리기를 만드는 경우 기본 구현이 암시적으로 호출되므로 메서드에서 직접 호출할 필요가 없습니다. 예를 들어 기본 페이지 클래스의 OnLoad 메서드는 Page_Load 메서드를 만드는지 여부에 관계없이 항상 호출됩니다. 그러나 override 키워드(Visual Basic에서는 Overrides)를 사용하여 페이지의 OnLoad 메서드를 재정의할 경우에는 기본 메서드를 명시적으로 호출해야 합니다. 예를 들어 페이지에서 OnLoad 메서드를 재정의하는 경우 기본 구현을 실행하려면 base.Load(Visual Basic에서는 MyBase.Load)를 호출해야 합니다.

추가된 컨트롤에 대한 후속 이벤트

런타임에 동적으로 컨트롤을 만들었거나 데이터 바인딩된 컨트롤의 템플릿 내에서 선언적으로 컨트롤을 작성한 경우 처음에는 해당 이벤트가 페이지의 다른 컨트롤 이벤트와 동기화되지 않습니다. 예를 들어, 런타임에 추가된 컨트롤의 경우 InitLoad 이벤트가 선언적으로 만든 다른 컨트롤의 동일한 이벤트보다 페이지 수명 주기에서 훨씬 더 늦게 발생할 수 있습니다. 따라서 동적으로 추가된 컨트롤과 템플릿의 컨트롤은 이를 인스턴스화한 시점부터 Controls 컬렉션에 추가된 동안의 이벤트를 따라잡을 때까지 해당 이벤트를 하나씩 발생시킵니다.

일반적으로 데이터 바인딩된 컨트롤을 중첩한 경우가 아니면 이 문제에 신경을 쓸 필요가 없습니다. 자식 컨트롤에 바인딩된 데이터가 있지만 해당 컨테이너 컨트롤의 데이터가 아직 바인딩되지 않았다면 자식 컨트롤의 데이터와 해당 컨테이너 컨트롤의 데이터가 동기화되지 않을 수 있습니다. 특히 자식 컨트롤의 데이터에서 컨테이너 컨트롤의 데이터 바인딩된 값을 기반으로 처리 작업을 수행하는 경우가 이에 해당합니다.

예를 들어, ListBox 컨트롤에 회사 간부 목록과 함께 회사 레코드를 각 행별로 표시하는 GridView를 생각해 볼 수 있습니다. 간부 목록을 채우기 위해 쿼리에 CompanyID를 사용하여 회사 간부 데이터를 검색하는 SqlDataSource 같은 데이터 소스 컨트롤에 ListBox 컨트롤을 바인딩할 수 있습니다.

DataSourceIDDataMember 같은 ListBox 컨트롤의 데이터 바인딩 속성을 선언적으로 설정한 경우 ListBox 컨트롤에서는 이를 포함하는 행의 DataBinding 이벤트가 진행되는 동안 해당 데이터 소스에 대한 바인딩을 시도합니다. 그러나 GridView 컨트롤의 RowDataBound 이벤트가 발생하기 전까지는 행의 CompanyID 필드에 값이 포함되지 않습니다. 이 경우 자식 컨트롤(ListBox 컨트롤)이 이를 포함하는 컨트롤(GridView 컨트롤)보다 먼저 바인딩되므로 이들 컨트롤의 데이터 바인딩 상태가 동기화되지 않습니다.

이 문제를 방지하려면 ListBox 컨트롤에 대한 데이터 소스 컨트롤을 ListBox 컨트롤 자체와 동일한 템플릿 항목에 배치하고 ListBox의 데이터 바인딩 속성을 선언적으로 설정하지 말아야 합니다. 대신 RowDataBound 이벤트가 진행되는 동안 런타임에 프로그래밍 방식으로 해당 속성을 설정하여 CompanyID 정보를 사용할 수 있게 되기 전까지는 ListBox 컨트롤의 데이터가 바인딩되지 않게 해야 합니다.

자세한 내용은 데이터 소스 컨트롤을 사용하여 데이터에 바인딩을 참조하십시오.

데이터 바인딩된 컨트롤에 대한 데이터 바인딩 이벤트

페이지 수명 주기와 데이터 바인딩 이벤트 사이의 관계를 쉽게 이해할 수 있도록 다음 표에서는 GridView, DetailsViewFormView 컨트롤 같은 데이터 바인딩된 컨트롤의 데이터 관련 이벤트 목록을 제공합니다.

컨트롤 이벤트 일반적인 용도

DataBinding

이 이벤트는 Page 개체 또는 컨테이너 컨트롤의 PreRender 이벤트가 발생하기 전에 데이터 바인딩된 컨트롤을 통해 발생하며 데이터에 대한 컨트롤의 바인딩 시작을 표시합니다.

필요한 경우 이 이벤트를 사용하여 데이터베이스 연결을 수동으로 열 수 있습니다. 일반적으로 데이터 소스 컨트롤을 사용하면 이러한 수동 연결이 필요 없습니다.

RowCreated(GridView에만 해당) 또는 ItemCreated(DataList, DetailsView, SiteMapPath, DataGrid, FormViewRepeater 컨트롤)

이 이벤트를 사용하면 데이터 바인딩에 의존하지 않는 내용을 조작할 수 있습니다. 예를 들어, 런타임에 프로그래밍 방식으로 GridView 컨트롤에 머리글 또는 바닥글 행의 서식을 추가할 수 있습니다.

RowDataBound(GridView에만 해당) 또는 ItemDataBound(DataList, SiteMapPath, DataGridRepeater 컨트롤)

이 이벤트가 발생하면 행이나 항목에 데이터를 사용할 수 있으므로 행 또는 항목 내에 관련 데이터를 표시하기 위해 자식 데이터 소스 컨트롤의 FilterExpression 속성을 설정하거나 데이터 형식을 지정할 수 있습니다.

DataBound

이 이벤트는 데이터 바인딩된 컨트롤에서 데이터 바인딩 작업의 끝을 표시합니다. GridView 컨트롤에서 데이터 바인딩은 모든 행과 모든 자식 컨트롤에 대해 완료됩니다.

이 이벤트를 사용하면 현재 컨트롤의 내용에 포함된 값에 의존하는 다른 컨트롤의 데이터 바인딩을 시작하거나 데이터 바인딩된 내용의 형식을 지정할 수 있습니다. 자세한 내용은 이 항목의 앞쪽에 있는 "추가된 컨트롤에 대한 후속 이벤트"를 참조하십시오.

로그인 컨트롤 이벤트

Login 컨트롤에서는 Web.config 파일의 설정을 사용하여 멤버 자격 인증을 자동으로 관리할 수 있습니다. 그러나 응용 프로그램에서 컨트롤의 작동 방식을 사용자 지정해야 하거나 페이지 수명 주기와 Login 컨트롤 이벤트가 어떻게 관련되어 있는지 이해하려는 경우 다음 표에 나와 있는 이벤트를 사용할 수도 있습니다.

컨트롤 이벤트 일반적인 용도

LoggingIn

이 이벤트는 페이지의 LoadComplete 이벤트가 발생한 후에 다시 게시하는 과정에서 발생합니다. 이는 로그인 프로세스의 시작을 표시합니다.

이 이벤트는 인증 프로세스를 시작하기 전에 발생해야 하는 작업에 사용합니다.

Authenticate

이 이벤트는 LoggingIn 이벤트 후에 발생합니다.

이 이벤트를 사용하면 Login 컨트롤의 기본 인증 동작을 재정의하거나 강화할 수 있습니다.

LoggedIn

이 이벤트는 사용자 이름과 암호를 인증한 후에 발생합니다.

이 이벤트를 사용하면 사용자를 다른 페이지로 리디렉션하거나 컨트롤의 텍스트를 동적으로 설정할 수 있습니다. 오류가 있거나 인증에 실패하면 이 이벤트가 발생하지 않습니다.

LoginError

이 이벤트는 인증에 성공하지 못한 경우 발생합니다.

이 이벤트를 사용하면 문제를 설명하는 텍스트를 컨트롤에 설정하거나 사용자를 다른 페이지로 리디렉션할 수 있습니다.

참고 항목

+ Recent posts