ASP.NET 1.x에서 개발자는 인라인 코드 모델과 코드 숨김 코드 모델 중에서 선택할 수 있었습니다. 코드 숨김은 지시문의 Src 특성 또는 CodeBehind 특성을 @Page 사용하여 구현할 수 있습니다. ASP.NET 2.0에서는 개발자가 여전히 인라인 코드와 코드 숨김 중에서 선택할 수 있지만 코드 숨김 모델이 크게 향상되었습니다.
ASP.NET 1.x에서 개발자는 인라인 코드 모델과 코드 숨김 코드 모델 중에서 선택할 수 있었습니다. 코드 숨김은 지시문의 Src 특성 또는 CodeBehind 특성을 @Page 사용하여 구현할 수 있습니다. ASP.NET 2.0에서는 개발자가 여전히 인라인 코드와 코드 숨김 중에서 선택할 수 있지만 코드 숨김 모델이 크게 향상되었습니다.
Code-Behind 모델의 향상된 기능
ASP.NET 2.0에서 코드 숨김 모델의 변경 내용을 완전히 이해하기 위해 ASP.NET 1.x에 존재할 때 모델을 신속하게 검토하는 것이 가장 좋습니다.
ASP.NET 1.x의 Code-Behind 모델
ASP.NET 1.x에서 코드 숨김 모델은 ASPX 파일(Webform)과 프로그래밍 코드를 포함하는 코드 숨김 파일로 구성되었습니다. 두 파일은 ASPX 파일의 @Page 지시문을 사용하여 연결되었습니다. ASPX 페이지의 각 컨트롤에는 코드 숨김 파일에 해당 선언이 instance 변수로 있습니다. 코드 숨김 파일에는 이벤트 바인딩에 대한 코드와 Visual Studio 디자이너에 필요한 생성된 코드도 포함되어 있습니다. 이 모델은 상당히 잘 작동했지만 ASPX 페이지의 모든 ASP.NET 요소에 코드 숨김 파일에 해당 코드가 필요했기 때문에 코드와 콘텐츠가 제대로 분리되지 않았습니다. 예를 들어 디자이너가 Visual Studio IDE 외부의 ASPX 파일에 새 서버 컨트롤을 추가한 경우 코드 숨김 파일에 해당 컨트롤에 대한 선언이 없으므로 애플리케이션이 중단됩니다.
ASP.NET 2.0의 Code-Behind 모델
ASP.NET 2.0은 이 모델을 크게 개선합니다. ASP.NET 2.0에서 코드 숨김은 ASP.NET 2.0에 제공된 새로운 부분 클래스 를 사용하여 구현됩니다. ASP.NET 2.0의 코드 숨김 클래스는 부분 클래스로 정의됩니다. 즉, 클래스 정의의 일부만 포함됩니다. 클래스 정의의 나머지 부분은 런타임에 ASPX 페이지를 사용하거나 웹 사이트가 미리 컴파일될 때 ASP.NET 2.0에서 동적으로 생성됩니다. 코드 숨김 파일과 ASPX 페이지 간의 링크는 @ Page 지시문을 사용하여 계속 설정됩니다. 그러나 이제 CodeBehind 또는 Src 특성 대신 ASP.NET 2.0에서 CodeFile 특성을 사용합니다. Inherits 특성은 페이지의 클래스 이름을 지정하는 데도 사용됩니다.
일반적인 @ Page 지시문은 다음과 같을 수 있습니다.
<%@Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
ASP.NET 2.0 코드 숨김 파일의 일반적인 클래스 정의는 다음과 같습니다.
public partial class _Default : System.Web.UI.Page
참고
C# 및 Visual Basic은 현재 부분 클래스를 지원하는 유일한 관리되는 언어입니다. 따라서 J#을 사용하는 개발자는 ASP.NET 2.0에서 코드 숨김 모델을 사용할 수 없습니다.
이제 개발자가 만든 코드만 포함된 코드 파일이 있으므로 새 모델은 코드 숨김 모델을 향상시킵니다. 또한 코드 숨김 파일에 instance 변수 선언이 없으므로 코드와 콘텐츠를 진정한 분리를 제공합니다.
참고
ASPX 페이지의 부분 클래스는 이벤트 바인딩이 발생하는 위치이므로 Visual Basic 개발자는 코드 숨김의 Handles 키워드(keyword) 사용하여 이벤트를 바인딩하여 약간의 성능 향상을 실현할 수 있습니다. C#에는 동등한 키워드(keyword) 없습니다.
새 @ 페이지 지시문 특성
ASP.NET 2.0은 @ Page 지시문에 많은 새 특성을 추가합니다. 다음 특성은 ASP.NET 2.0의 새로운 특성입니다.
Async
비동기 특성을 사용하면 페이지를 비동기적으로 실행하도록 구성할 수 있습니다. 이 모듈의 뒷부분에 있는 비동기 페이지를 잘 다룹니다.
비동기 시간 제한
비동기 페이지의 시간 제한을 지정했습니다. 기본값은 45초입니다.
Codefile
CodeFile 특성은 Visual Studio 2002/2003의 CodeBehind 특성을 대체합니다.
CodeFileBaseClass
CodeFileBaseClass 특성은 여러 페이지가 단일 기본 클래스에서 파생되도록 하려는 경우에 사용됩니다. ASP.NET 부분 클래스를 구현하기 때문에 이 특성이 없으면 ASPX 페이지에 선언된 컨트롤을 참조하기 위해 공유 공통 필드를 사용하는 기본 클래스가 제대로 작동하지 않습니다. NET 컴파일 엔진은 페이지의 컨트롤에 따라 새 멤버를 자동으로 만듭니다. 따라서 ASP.NET 두 개 이상의 페이지에 공통 기본 클래스를 사용하려면 CodeFileBaseClass 특성에서 기본 클래스를 지정한 다음 해당 기본 클래스에서 각 페이지 클래스를 파생해야 합니다. 이 특성을 사용하는 경우에도 CodeFile 특성이 필요합니다.
CompilationMode
이 특성을 사용하면 ASPX 페이지의 CompilationMode 속성을 설정할 수 있습니다. CompilationMode 속성은 Always, Auto 및 Never 값을 포함하는 열거형입니다. 기본값은 Always입니다. 자동 설정은 가능한 경우 ASP.NET 페이지를 동적으로 컴파일하지 못하게 합니다. 동적 컴파일에서 페이지를 제외하면 성능이 향상됩니다. 그러나 제외된 페이지에 컴파일해야 하는 코드가 포함된 경우 페이지를 검색할 때 오류가 throw됩니다.
이벤트 유효성 검사 사용
이 특성은 포스트백 및 콜백 이벤트의 유효성을 검사할지 여부를 지정합니다. 이 기능을 사용하도록 설정하면 포스트백 또는 콜백 이벤트에 대한 인수가 원래 렌더링된 서버 컨트롤에서 시작되었는지 확인합니다.
테마 지정 사용
이 특성은 페이지에서 ASP.NET 테마를 사용할지 여부를 지정합니다. 기본값은 false입니다. ASP.NET 테마는 모듈 10에서 다룹니다.
LinePragmas
이 특성은 컴파일 중에 줄 pragma를 추가할지 여부를 지정합니다. 줄 pragma는 디버거가 코드의 특정 섹션을 표시하는 데 사용하는 옵션입니다.
MaintainScrollPositionOnPostback
이 특성은 포스트백 간에 스크롤 위치를 유지하기 위해 JavaScript를 페이지에 삽입할지 여부를 지정합니다. 이 특성은 기본적으로 false 입니다.
이 특성이 true이면 ASP.NET 다음과 같은 스크립트> 블록을 포스트백에 추가<합니다.
<script src="/website/WebResource.axd?d=jBAvpwrdOM_V_Xzeox989A2 &t=632653133849531250" type="text/javascript"> </script>
이 스크립트 블록의 src는 WebResource.axd입니다. 이 리소스는 물리적 경로가 아닙니다. 이 스크립트가 요청되면 ASP.NET 스크립트를 동적으로 빌드합니다.
MasterPageFile
이 특성은 현재 페이지의 master 페이지 파일을 지정합니다. 경로는 상대적이거나 절대적일 수 있습니다. 마스터 페이지는 모듈 4에서 다룹니다.
스타일시트 테마
이 특성을 사용하면 ASP.NET 2.0 테마로 정의된 사용자 인터페이스 모양 속성을 재정의할 수 있습니다. 테마는 모듈 10에서 다룹니다.
테마 값
페이지의 테마를 지정합니다. StyleSheetTheme 특성에 값을 지정하지 않으면 Theme 특성은 페이지의 컨트롤에 적용된 모든 스타일을 재정의합니다.
제목 값
페이지의 제목을 설정합니다. 여기에 지정된 값은 렌더링된 페이지의 제목> 요소에 표시됩니다<.
ViewStateEncryptionMode
ViewStateEncryptionMode 열거형의 값을 설정합니다. 사용 가능한 값은 Always, Auto 및 Never입니다. 기본값은 Auto입니다. 이 특성이 Auto 값으로 설정되면 viewstate는 RegisterRequiresViewStateEncryption 메서드를 호출하여 요청하는 컨트롤로 암호화됩니다.
@ Page 지시문을 통해 공용 속성 값 설정
ASP.NET 2.0에서 @ Page 지시문의 또 다른 새로운 기능은 기본 클래스의 public 속성의 초기 값을 설정하는 기능입니다. 예를 들어 기본 클래스에 SomeText 라는 공용 속성이 있고 페이지가 로드될 때 Hello 로 초기화하려고 한다고 가정합니다. 다음과 같이 @ Page 지시문에서 값을 설정하기만 하면 됩니다.
<%@Page Language="C#" SomeText="Hello!" Inherits="PageBase" %>
@ Page 지시문의 SomeText 특성은 기본 클래스에 있는 SomeText 속성의 초기 값을 Hello!로 설정합니다. 아래 비디오는 @ Page 지시문을 사용하여 기본 클래스에서 public 속성의 초기 값을 설정하는 연습입니다.
페이지 클래스의 새 공용 속성
다음 공용 속성은 ASP.NET 2.0의 새로운 속성입니다.
AppRelativeTemplateSourceDirectory
페이지 또는 컨트롤에 대한 애플리케이션 상대 경로를 반환합니다. 예를 들어 에 있는 http://app/folder/page.aspx페이지의 경우 속성은 ~/folder/를 반환합니다.
AppRelativeVirtualPath
페이지 또는 컨트롤에 대한 상대 가상 디렉터리 경로를 반환합니다. 예를 들어 에 http://app/folder/page.aspx있는 페이지의 경우 속성은 ~/folder/page.aspx를 반환합니다.
AsyncTimeout
비동기 페이지 처리에 사용되는 시간 제한을 가져오거나 설정합니다. (비동기 페이지는 이 모듈의 뒷부분에서 다룹니다.)
ClientQueryString
요청된 URL의 쿼리 문자열 부분을 반환하는 읽기 전용 속성입니다. 이 값은 URL로 인코딩됩니다. HttpServerUtility 클래스의 UrlDecode 메서드를 사용하여 디코딩할 수 있습니다.
ClientScript
이 속성은 ASP를 관리하는 데 사용할 수 있는 ClientScriptManager 개체를 반환합니다. 클라이언트 쪽 스크립트의 NET 방출. (ClientScriptManager 클래스는 이 모듈의 뒷부분에서 설명합니다.)
EnableEventValidation
이 속성은 이벤트 유효성 검사를 포스트백 및 콜백 이벤트에 사용할 수 있는지 여부를 제어합니다. 사용하도록 설정하면 포스트백 또는 콜백 이벤트에 대한 인수가 원래 렌더링된 서버 컨트롤에서 시작되었는지 확인합니다.
EnableTheming
이 속성은 ASP.NET 2.0 테마가 페이지에 적용되는지 여부를 지정하는 부울을 가져오거나 설정합니다.
Form
이 속성은 ASPX 페이지의 HTML 양식을 HtmlForm 개체로 반환합니다.
헤더
이 속성은 페이지 머리글이 포함된 HtmlHead 개체에 대한 참조를 반환합니다. 반환된 HtmlHead 개체를 사용하여 스타일시트, 메타 태그 등을 가져오기/설정할 수 있습니다.
IdSeparator
이 읽기 전용 속성은 ASP.NET 페이지의 컨트롤에 대한 고유 ID를 빌드할 때 컨트롤 식별자를 구분하는 데 사용되는 문자를 가져옵니다. 코드에서 직접 사용하기에 적합하지 않습니다.
IsAsync
이 속성을 사용하면 비동기 페이지를 사용할 수 있습니다. 비동기 페이지는 이 모듈의 뒷부분에서 설명합니다.
IsCallback
이 읽기 전용 속성은 페이지가 콜백의 결과인 경우 true 를 반환합니다. 콜백은 이 모듈의 뒷부분에서 설명합니다.
IsCrossPagePostBack
이 읽기 전용 속성은 페이지가 교차 페이지 포스트백의 일부인 경우 true 를 반환합니다. 교차 페이지 포스트백은 이 모듈의 뒷부분에서 다룹니다.
항목
페이지 컨텍스트에 저장된 모든 개체를 포함하는 IDictionary instance 대한 참조를 반환합니다. 이 IDictionary 개체에 항목을 추가할 수 있으며 컨텍스트의 수명 동안 사용할 수 있습니다.
MaintainScrollPositionOnPostBack
이 속성은 ASP.NET 포스트백이 발생한 후 브라우저에서 페이지 스크롤 위치를 유지하는 JavaScript를 내보내는지 여부를 제어합니다. (이 속성의 세부 정보는 이 모듈의 앞부분에서 설명했습니다.)
마스터
이 읽기 전용 속성은 master 페이지가 적용된 페이지의 MasterPage instance 대한 참조를 반환합니다.
MasterPageFile
페이지의 master 페이지 파일 이름을 가져오거나 설정합니다. 이 속성은 PreInit 메서드에서만 설정할 수 있습니다.
MaxPageStateFieldLength
이 속성은 페이지 상태의 최대 길이를 바이트 단위로 가져오거나 설정합니다. 속성이 양수로 설정된 경우 페이지 보기 상태는 지정된 바이트 수를 초과하지 않도록 여러 숨겨진 필드로 나뉩니다. 속성이 음수이면 뷰 상태가 청크로 분할되지 않습니다.
PageAdapter
요청 브라우저에 대한 페이지를 수정하는 PageAdapter 개체에 대한 참조를 반환합니다.
Previouspage
Server.Transfer 또는 페이지 간 포스트백의 경우 이전 페이지에 대한 참조를 반환합니다.
Skinid
페이지에 적용할 ASP.NET 2.0 스킨을 지정합니다.
Stylesheettheme
이 속성은 페이지에 적용되는 스타일시트를 가져오거나 설정합니다.
TemplateControl
페이지에 대한 포함 컨트롤에 대한 참조를 반환합니다.
테마
페이지에 적용된 ASP.NET 2.0 테마의 이름을 가져오거나 설정합니다. 이 값은 PreInit 메서드 이전에 설정해야 합니다.
제목
이 속성은 페이지 머리글에서 가져온 대로 페이지의 제목을 가져오거나 설정합니다.
ViewStateEncryptionMode
페이지의 ViewStateEncryptionMode를 가져오거나 설정합니다. 이 모듈의 앞부분에서 이 속성에 대한 자세한 설명을 참조하세요.
페이지 클래스의 새 보호 속성
다음은 ASP.NET 2.0에서 Page 클래스의 새 보호 속성입니다.
어댑터
요청한 디바이스에서 페이지를 렌더링하는 ControlAdapter에 대한 참조를 반환합니다.
AsyncMode
이 속성은 페이지가 비동기적으로 처리되는지 여부를 나타냅니다. 코드에서 직접 사용하지 않고 런타임에서 사용하기 위한 것입니다.
ClientIDSeparator
이 속성은 컨트롤에 대한 고유한 클라이언트 ID를 만들 때 구분 기호로 사용되는 문자를 반환합니다. 코드에서 직접 사용하지 않고 런타임에서 사용하기 위한 것입니다.
PageStatePersister
이 속성은 페이지의 PageStatePersister 개체를 반환합니다. 이 속성은 주로 ASP.NET 제어 개발자에 의해 사용 됩니다.
UniqueFilePathSuffix
이 속성은 캐싱 브라우저의 파일 경로에 추가되는 고유한 접미사를 반환합니다. 기본값은 __ufps= 및 6자리 숫자입니다.
페이지 클래스에 대한 새 공용 메서드
다음 공용 메서드는 ASP.NET 2.0의 Page 클래스에 새로 추가되었습니다.
AddOnPreRenderCompleteAsync
이 메서드는 비동기 페이지 실행에 대 한 이벤트 처리기 대리자를 등록 합니다. 비동기 페이지는 이 모듈의 뒷부분에서 설명합니다.
ApplyStyleSheetSkin
페이지 스타일시트에 있는 속성을 페이지에 적용합니다.
ExecuteRegisteredAsyncTasks
이 메서드는 비동기 작업입니다.
GetValidators
지정된 유효성 검사 그룹에 대한 유효성 검사기 컬렉션을 반환하거나, 지정하지 않은 경우 기본 유효성 검사 그룹을 반환합니다.
RegisterAsyncTask
이 메서드는 새 비동기 작업을 등록합니다. 비동기 페이지는 이 모듈의 뒷부분에서 다룹니다.
RegisterRequiresControlState
이 메서드는 페이지 컨트롤 상태를 유지해야 한다는 ASP.NET 알려줍니다.
RegisterRequiresViewStateEncryption
이 메서드는 페이지 뷰스테이트에 암호화가 필요하다는 것을 ASP.NET 알려줍니다.
ResolveClientUrl
이미지 등에 대한 클라이언트 요청에 사용할 수 있는 상대 URL을 반환합니다.
SetFocus
이 메서드는 페이지가 처음 로드될 때 지정된 컨트롤에 포커스를 설정합니다.
UnregisterRequiresControlState
이 메서드는 더 이상 제어 상태 지속성을 필요로 하지 않으므로 전달되는 컨트롤의 등록을 취소합니다.
페이지 수명 주기 변경
ASP.NET 2.0의 페이지 수명 주기는 크게 변경되지 않았지만 알아야 할 몇 가지 새로운 방법이 있습니다. ASP.NET 2.0 페이지 수명 주기는 아래에 설명되어 있습니다.
PreInit(ASP.NET 2.0의 새로운 기능)
PreInit 이벤트는 개발자가 액세스할 수 있는 수명 주기의 초기 단계입니다. 이 이벤트를 추가하면 프로그래밍 방식으로 ASP.NET 2.0 테마, master 페이지, ASP.NET 2.0 프로필에 대한 액세스 속성 등을 변경할 수 있습니다. 포스트백 상태인 경우 Viewstate가 수명 주기의 이 시점에서 컨트롤에 아직 적용되지 않았다는 것을 깨닫는 것이 중요합니다. 따라서 개발자가 이 단계에서 컨트롤의 속성을 변경하는 경우 나중에 페이지 수명 주기에서 덮어쓸 수 있습니다.
Init
Init 이벤트가 ASP.NET 1.x에서 변경되지 않았습니다. 여기에서 페이지에서 컨트롤의 속성을 읽거나 초기화할 수 있습니다. 이 단계에서는 master 페이지, 테마 등이 이미 페이지에 적용되어 있습니다.
InitComplete(2.0의 새로운 기능)
InitComplete 이벤트는 페이지 초기화 단계가 끝날 때 호출됩니다. 수명 주기의 이 시점에서 페이지의 컨트롤에 액세스할 수 있지만 해당 상태는 아직 채워지지 않았습니다.
PreLoad(2.0의 새로운 기능)
이 이벤트는 모든 포스트백 데이터가 적용되고 Page_Load 직전에 호출됩니다.
로드
Load 이벤트가 ASP.NET 1.x에서 변경되지 않았습니다.
LoadComplete(2.0의 새로운 기능)
LoadComplete 이벤트는 페이지 로드 단계의 마지막 이벤트입니다. 이 단계에서는 모든 포스트백 및 뷰스테이트 데이터가 페이지에 적용되었습니다.
Prerender
페이지에 동적으로 추가된 컨트롤에 대해 viewstate를 올바르게 유지 관리하려면 PreRender 이벤트를 마지막으로 추가할 수 있습니다.
PreRenderComplete(2.0의 새로운 기능)
PreRenderComplete 단계에서 모든 컨트롤이 페이지에 추가되었으며 페이지를 렌더링할 준비가 되었습니다. PreRenderComplete 이벤트는 페이지 뷰스테이션이 저장되기 전에 발생한 마지막 이벤트입니다.
SaveStateComplete(2.0의 새로운 기능)
SaveStateComplete 이벤트는 모든 페이지 뷰스테이트 및 컨트롤 상태가 저장된 직후에 호출됩니다. 페이지가 실제로 브라우저에 렌더링되기 전의 마지막 이벤트입니다.
렌더링
Render 메서드는 ASP.NET 1.x 이후 변경되지 않았습니다. 여기서 HtmlTextWriter가 초기화되고 페이지가 브라우저로 렌더링됩니다.
ASP.NET 2.0의 페이지 간 포스트백
ASP.NET 1.x에서는 같은 페이지에 포스트백을 게시해야 했습니다. 페이지 간 포스트백은 허용되지 않았습니다. ASP.NET 2.0은 IButtonControl 인터페이스를 통해 다른 페이지에 다시 게시하는 기능을 추가합니다. 새 IButtonControl 인터페이스(타사 사용자 지정 컨트롤 외에도 Button, LinkButton 및 ImageButton)를 구현하는 모든 컨트롤은 PostBackUrl 특성을 사용하여 이 새로운 기능을 활용할 수 있습니다. 다음 코드에서는 두 번째 페이지에 다시 게시하는 Button 컨트롤을 보여 있습니다.
<asp:Button ID="SubmitReport" PostBackUrl="~/Default.aspx" runat="server" Text="Submit Report" />
페이지가 다시 게시되면 두 번째 페이지의 PreviousPage 속성을 통해 포스트백을 시작하는 페이지에 액세스할 수 있습니다. 이 기능은 컨트롤이 다른 페이지에 다시 게시될 때 ASP.NET 2.0이 페이지로 렌더링되는 새로운 WebForm_DoPostBackWithOptions 클라이언트 쪽 함수를 통해 구현됩니다. 이 JavaScript 함수는 클라이언트에 스크립트를 내보내는 새 WebResource.axd 처리기에서 제공됩니다.
아래 비디오는 교차 페이지 포스트백의 연습입니다.
페이지 간 포스트백에 대한 자세한 내용
Viewstate
페이지 간 포스트백 시나리오의 첫 번째 페이지에서 viewstate에 어떤 일이 발생하는지 이미 스스로에게 물었을 수 있습니다. 결국 IPostBackDataHandler를 구현하지 않는 모든 컨트롤은 viewstate를 통해 상태를 유지하므로 페이지 간 포스트백의 두 번째 페이지에서 해당 컨트롤의 속성에 액세스하려면 페이지의 viewstate에 액세스할 수 있어야 합니다. ASP.NET 2.0은 __PREVIOUSPAGE라는 두 번째 페이지의 새 숨겨진 필드를 사용하여 이 시나리오를 처리합니다. __PREVIOUSPAGE 양식 필드에는 첫 번째 페이지의 viewstate가 포함되어 있으므로 두 번째 페이지의 모든 컨트롤 속성에 액세스할 수 있습니다.
FindControl 우회
페이지 간 포스트백의 비디오 연습에서 FindControl 메서드를 사용하여 첫 번째 페이지의 TextBox 컨트롤에 대한 참조를 가져옵니다. 이 메서드는 해당 용도로 잘 작동하지만 FindControl은 비용이 많이 들고 추가 코드를 작성해야 합니다. 다행히 ASP.NET 2.0은 많은 시나리오에서 작동하는 이 목적을 위해 FindControl에 대한 대안을 제공합니다. PreviousPageType 지시문을 사용하면 TypeName 또는 VirtualPath 특성을 사용하여 이전 페이지에 대한 강력한 형식의 참조를 사용할 수 있습니다. TypeName 특성을 사용하면 이전 페이지의 형식을 지정할 수 있지만 VirtualPath 특성을 사용하면 가상 경로를 사용하여 이전 페이지를 참조할 수 있습니다. PreviousPageType 지시문을 설정한 후에는 컨트롤 등을 노출해야 합니다. 공용 속성을 사용하여 액세스를 허용하려는 입니다.
랩 1 페이지 간 포스트백
이 랩에서는 ASP.NET 2.0의 새로운 페이지 간 포스트백 기능을 사용하는 애플리케이션을 만듭니다.
Visual Studio 2005를 열고 새 ASP.NET 웹 사이트를 만듭니다.
page2.aspx라는 새 웹 폼을 추가합니다.
디자인 보기에서 Default.aspx를 열고 단추 컨트롤과 TextBox 컨트롤을 추가합니다.
- Button 컨트롤에 SubmitButton 의 ID를 지정하고 TextBox 컨트롤에 UserName ID를 지정합니다.
- Button의 PostBackUrl 속성을 page2.aspx로 설정합니다.
원본 보기에서 page2.aspx를 엽니다.
아래와 같이 @ PreviousPageType 지시문을 추가합니다.
page2.aspx 코드 숨김의 Page_Load 다음 코드를 추가합니다.
Response.Write(PreviousPage.UserName.Text);빌드 메뉴에서 빌드를 클릭하여 프로젝트를 빌드합니다.
Default.aspx의 코드 숨김에 다음 코드를 추가합니다.
public TextBox txtUserName { get { return this.UserName; } }page2.aspx의 Page_Load 다음으로 변경합니다.
Response.Write(PreviousPage.txtUserName.Text);프로젝트를 빌드합니다.
프로젝트를 실행합니다.
TextBox에 이름을 입력하고 단추를 클릭합니다.
결과는 무엇인가요?
ASP.NET 2.0의 비동기 페이지
ASP.NET 많은 경합 문제는 외부 호출(예: 웹 서비스 또는 데이터베이스 호출), 파일 IO 대기 시간 등의 대기 시간으로 인해 발생합니다. ASP.NET 애플리케이션에 대한 요청이 이루어지면 ASP.NET 해당 작업자 스레드 중 하나를 사용하여 해당 요청을 서비스합니다. 해당 요청은 요청이 완료되고 응답이 전송될 때까지 해당 스레드를 소유합니다. ASP.NET 2.0은 페이지를 비동기적으로 실행하는 기능을 추가하여 이러한 유형의 문제에 대한 대기 시간 문제를 resolve. 즉, 작업자 스레드는 요청을 시작한 다음 다른 스레드에 추가 실행을 전달하여 사용 가능한 스레드 풀로 신속하게 돌아갈 수 있습니다. 파일 IO, 데이터베이스 호출 등 가 완료되었습니다. 요청을 완료하기 위해 스레드 풀에서 새 스레드를 가져옵니다.
페이지를 비동기적으로 실행하는 첫 번째 단계는 다음과 같이 페이지 지시문의 Async 특성을 설정하는 것입니다.
<%@ Page Async="true" %>
이 특성은 ASP.NET 페이지에 대한 IHttpAsyncHandler를 구현하도록 지시합니다.
다음 단계는 PreRender 이전 페이지의 수명 주기 지점에서 AddOnPreRenderCompleteAsync 메서드를 호출하는 것입니다. (이 메서드는 일반적으로 Page_Load 호출됩니다.) AddOnPreRenderCompleteAsync 메서드는 두 개의 매개 변수를 사용합니다. BeginEventHandler 및 EndEventHandler. BeginEventHandler는 IAsyncResult를 반환한 다음 EndEventHandler에 매개 변수로 전달됩니다.
아래 비디오는 비동기 페이지 요청의 연습입니다.
참고
EndEventHandler가 완료될 때까지 비동기 페이지는 브라우저에 렌더링되지 않습니다. 의심의 여지가 있지만 일부 개발자는 비동기 요청이 비동기 콜백과 유사하다고 생각할 것입니다. 그렇지 않다는 것을 깨닫는 것이 중요합니다. 비동기 요청의 이점은 첫 번째 작업자 스레드를 스레드 풀로 반환하여 새 요청을 처리하여 IO 바인딩 등으로 인한 경합을 줄일 수 있다는 것입니다.
ASP.NET 2.0의 스크립트 콜백
웹 개발자는 항상 콜백과 관련된 깜박임을 방지하는 방법을 찾고 있습니다. ASP.NET 1.x에서 SmartNavigation은 깜박임을 방지하는 가장 일반적인 방법이었지만 SmartNavigation은 클라이언트에서 구현의 복잡성으로 인해 일부 개발자에게 문제를 일으켰습니다. ASP.NET 2.0은 스크립트 콜백을 사용하여 이 문제를 해결합니다. 스크립트 콜백은 XMLHttp를 활용하여 JavaScript를 통해 웹 서버에 대한 요청을 만듭니다. XMLHttp 요청은 브라우저의 DOM을 통해 조작할 수 있는 XML 데이터를 반환합니다. XMLHttp 코드는 새 WebResource.axd 처리기에 의해 사용자로부터 숨겨집니다.
ASP.NET 2.0에서 스크립트 콜백을 구성하기 위해 필요한 몇 가지 단계가 있습니다.
1단계: ICallbackEventHandler 인터페이스 구현
ASP.NET 스크립트 콜백에 참여하는 것으로 페이지를 인식하려면 ICallbackEventHandler 인터페이스를 구현해야 합니다. 다음과 같이 코드 숨김 파일에서 이 작업을 수행할 수 있습니다.
public partial class _Default : System.Web.UI.Page, ICallbackEventHandler
다음과 같이 @ Implements 지시문을 사용하여 이 작업을 수행할 수도 있습니다.
<%@ Implements Interface="System.Web.UI.ICallbackEventHandler" %>
일반적으로 인라인 ASP.NET 코드를 사용할 때 @ Implements 지시문을 사용합니다.
2단계: GetCallbackEventReference 호출
앞에서 설명한 대로 XMLHttp 호출은 WebResource.axd 처리기에 캡슐화됩니다. 페이지가 렌더링되면 ASP.NET WebResource.axd에서 제공하는 클라이언트 스크립트인 WebForm_DoCallback 호출을 추가합니다. WebForm_DoCallback 함수는 콜백에 대한 __doPostBack 함수를 대체합니다. __doPostBack 페이지에 양식을 프로그래밍 방식으로 제출합니다. 콜백 시나리오에서는 포스트백을 방지하려고 하므로 __doPostBack 충분하지 않습니다.
참고
__doPostBack 클라이언트 스크립트 콜백 시나리오에서 여전히 페이지로 렌더링됩니다. 그러나 콜백에는 사용되지 않습니다.
WebForm_DoCallback 클라이언트 쪽 함수에 대한 인수는 일반적으로 Page_Load 호출되는 서버 쪽 함수 GetCallbackEventReference를 통해 제공됩니다. GetCallbackEventReference에 대한 일반적인 호출은 다음과 같습니다.
// Set up the JavaScript callback string cbRef = cm.GetCallbackEventReference(this, "document.getElementById('ddlCompany').value", "ShowCompanyName", "null", true);
참고
이 경우 cm은 ClientScriptManager의 instance. ClientScriptManager 클래스는 이 모듈의 뒷부분에서 다룹니다.
GetCallbackEventReference에는 여러 오버로드된 버전이 있습니다. 이 경우 인수는 다음과 같습니다.
this
GetCallbackEventReference가 호출되는 컨트롤에 대한 참조입니다. 이 경우 페이지 자체입니다.
document.getElementById('ddlCompany').value
클라이언트 쪽 코드에서 서버 쪽 이벤트로 전달될 문자열 인수입니다. 이 경우 Im이 ddlCompany라는 드롭다운 값을 전달합니다.
ShowCompanyName
서버 쪽 콜백 이벤트의 반환 값(문자열)을 수락할 클라이언트 쪽 함수의 이름입니다. 이 함수는 서버 쪽 콜백이 성공한 경우에만 호출됩니다. 따라서 견고성을 위해 일반적으로 오류가 발생할 경우 실행할 클라이언트 쪽 함수의 이름을 지정하는 추가 문자열 인수를 사용하는 GetCallbackEventReference의 오버로드된 버전을 사용하는 것이 좋습니다.
null
서버에 대한 콜백 전에 시작된 클라이언트 쪽 함수를 나타내는 문자열입니다. 이 경우 이러한 스크립트가 없으므로 인수는 null입니다.
true
콜백을 비동기적으로 수행할지 여부를 지정하는 부울입니다.
클라이언트에서 WebForm_DoCallback 호출하면 이러한 인수가 전달됩니다. 따라서 이 페이지가 클라이언트에서 렌더링되면 해당 코드는 다음과 같이 표시됩니다.
WebForm_DoCallback('__Page',document.getElementById('ddlCompany').value, ShowCompanyName,null,null,true)
클라이언트에서 함수의 서명은 약간 다릅니다. 클라이언트 쪽 함수는 5개의 문자열과 부울을 전달합니다. 위의 예제에서 null인 추가 문자열에는 서버 쪽 콜백의 오류를 처리하는 클라이언트 쪽 함수가 포함되어 있습니다.
3단계: Client-Side 제어 이벤트 후크
위의 GetCallbackEventReference의 반환 값이 문자열 변수에 할당되었습니다. 이 문자열은 콜백을 시작하는 컨트롤에 대한 클라이언트 쪽 이벤트를 후크하는 데 사용됩니다. 이 예제에서는 페이지의 드롭다운에 의해 콜백이 시작되므로 OnChange 이벤트를 후크하려고 합니다.
클라이언트 쪽 이벤트를 연결하려면 다음과 같이 클라이언트 쪽 태그에 처리기를 추가하면 됩니다.
// Hook the JavaScript function to the onchange event of the dropdown ddlCompany.Attributes["onchange"] = String.Format("javascript:{0}", cbRef);
cbRef는 GetCallbackEventReference 호출의 반환 값입니다. 여기에는 위에 표시된 WebForm_DoCallback 대한 호출이 포함됩니다.
4단계: Client-Side 스크립트 등록
GetCallbackEventReference 호출은 서버 쪽 콜백이 성공할 때 ShowCompanyName 이라는 클라이언트 쪽 스크립트가 실행되도록 지정했습니다. 해당 스크립트는 ClientScriptManager instance 사용하여 페이지에 추가해야 합니다. (ClientScriptManager 클래스는 이 모듈의 뒷부분에서 설명합니다.) 이렇게 하면 다음과 같습니다.
System.Text.StringBuilder clientScript = new System.Text.StringBuilder(""); ClientScriptManager cm = Page.ClientScript; // Create the client script clientScript.Append("function ShowCompanyName(companyName)"); clientScript.Append("{"); clientScript.Append("document.getElementById('CoClicked').innerHTML = \"You chose \" + companyName + \".\";"); clientScript.Append("}"); cm.RegisterClientScriptBlock(this.GetType(), "showCo", clientScript.ToString(), true);
5단계: ICallbackEventHandler 인터페이스의 메서드 호출
ICallbackEventHandler에는 코드에서 구현해야 하는 두 가지 메서드가 포함되어 있습니다. RaiseCallbackEvent 및 GetCallbackEvent입니다.
RaiseCallbackEvent 는 문자열을 인수로 사용하고 아무 것도 반환하지 않습니다. 문자열 인수는 클라이언트 쪽 호출에서 WebForm_DoCallback 전달됩니다. 이 경우 해당 값은 ddlCompany라는 드롭다운의 값 특성입니다. 서버 쪽 코드는 RaiseCallbackEvent 메서드에 배치되어야 합니다. 예를 들어 콜백이 외부 리소스에 대해 WebRequest를 만드는 경우 해당 코드는 RaiseCallbackEvent에 배치되어야 합니다.
GetCallbackEvent 는 클라이언트에 대한 콜백 반환을 처리합니다. 인수를 사용하지 않고 문자열을 반환합니다. 반환하는 문자열은 클라이언트 쪽 함수(이 경우 ShowCompanyName)에 인수로 전달됩니다.
위의 단계를 완료하면 ASP.NET 2.0에서 스크립트 콜백을 수행할 준비가 된 것입니다.
ASP.NET 스크립트 콜백은 XMLHttp 호출을 지원하는 모든 브라우저에서 지원됩니다. 여기에는 현재 사용 중인 모든 최신 브라우저가 포함됩니다. 인터넷 Explorer XMLHttp ActiveX 개체를 사용하는 반면 다른 최신 브라우저(예정된 IE 7 포함)는 내장 XMLHttp 개체를 사용합니다. 브라우저가 콜백을 지원하는지 프로그래밍 방식으로 확인하려면 Request.Browser.SupportCallback 속성을 사용할 수 있습니다. 요청 클라이언트가 스크립트 콜백을 지원하는 경우 이 속성은 true 를 반환합니다.
ASP.NET 2.0에서 클라이언트 스크립트 작업
ASP.NET 2.0의 클라이언트 스크립트는 ClientScriptManager 클래스를 사용하여 관리됩니다. ClientScriptManager 클래스는 형식 및 이름을 사용하여 클라이언트 스크립트를 추적합니다. 이렇게 하면 동일한 스크립트가 페이지에 프로그래밍 방식으로 두 번 이상 삽입되지 않습니다.
참고
스크립트가 페이지에 성공적으로 등록되면 이후에도 동일한 스크립트를 등록하려고 하면 스크립트가 두 번째로 등록되지 않습니다. 중복 스크립트가 추가되지 않으며 예외가 발생하지 않습니다. 불필요한 계산을 방지하기 위해 스크립트를 두 번 이상 등록하지 않도록 스크립트가 이미 등록되어 있는지 확인하는 데 사용할 수 있는 메서드가 있습니다.
ClientScriptManager의 메서드는 모든 현재 ASP.NET 개발자에게 익숙해야 합니다.
RegisterClientScriptBlock
이 메서드는 렌더링된 페이지의 맨 위에 스크립트를 추가합니다. 이는 클라이언트에서 명시적으로 호출되는 함수를 추가하는 데 유용합니다.
이 메서드에는 두 가지 오버로드된 버전이 있습니다. 4개의 인수 중 3개가 공통적으로 사용됩니다. 관련 토폴로지는 다음과 같습니다.
type (string)
type 인수는 스크립트의 형식을 식별합니다. 일반적으로 페이지의 형식(이 형식)을 사용하는 것이 좋습니다. 형식에 대한 GetType())
key (string)
키 인수는 스크립트에 대한 사용자 정의 키입니다. 각 스크립트에 대해 고유해야 합니다. 이미 추가된 스크립트의 키와 형식이 동일한 스크립트를 추가하려고 하면 추가되지 않습니다.
script (string)
스크립트 인수는 추가할 실제 스크립트를 포함하는 문자열입니다. StringBuilder를 사용하여 스크립트를 만든 다음 StringBuilder에서 ToString() 메서드를 사용하여 스크립트 인수를 할당하는 것이 좋습니다.
3개의 인수만 사용하는 오버로드된 RegisterClientScriptBlock을 사용하는 경우 스크립트에 스크립트 요소(<스크립트> 및 </script>)를 포함해야 합니다.
네 번째 인수를 사용하는 RegisterClientScriptBlock의 오버로드를 사용하도록 선택할 수 있습니다. 네 번째 인수는 ASP.NET 스크립트 요소를 추가할지 여부를 지정하는 부울입니다. 이 인수가 true이면 스크립트에 스크립트 요소가 명시적으로 포함되지 않아야 합니다.
IsClientScriptBlockRegistered 메서드를 사용하여 스크립트가 이미 등록되었는지 확인합니다. 이렇게 하면 이미 등록된 스크립트를 다시 등록하지 않아도 됩니다.
RegisterClientScriptInclude(2.0의 새로운 기능)
RegisterClientScriptInclude 태그는 외부 스크립트 파일에 연결되는 스크립트 블록을 만듭니다. 두 개의 오버로드가 있습니다. 하나는 키와 URL을 사용합니다. 두 번째는 형식을 지정하는 세 번째 인수를 추가합니다.
예를 들어 다음 코드는 애플리케이션의 스크립트 폴더 루트에 있는 jsfunctions.js 연결하는 스크립트 블록을 생성합니다.
ClientScriptManager cm = Page.ClientScript; if(!cm.IsClientScriptIncludeRegistered("jsfunc")) { cm.RegisterClientScriptInclude(this.GetType(), "jsfunc", "/scripts/jsfunctions.js"); }
이 코드는 렌더링된 페이지에서 다음 코드를 생성합니다.
<script src="/scripts/jsfunctions.js" type="text/javascript"></script>
참고
스크립트 블록은 페이지 아래쪽에 렌더링됩니다.
IsClientScriptIncludeRegistered 메서드를 사용하여 스크립트가 이미 등록되었는지 확인합니다. 이렇게 하면 스크립트를 다시 등록하지 않아도 됩니다.
RegisterStartupScript
RegisterStartupScript 메서드는 RegisterClientScriptBlock 메서드와 동일한 인수를 사용합니다. RegisterStartupScript에 등록된 스크립트는 페이지가 로드된 후 OnLoad 클라이언트 쪽 이벤트 전에 실행됩니다. 1.X에서는 RegisterStartupScript에 등록된 스크립트가 닫는 </form> 태그 바로 앞에 배치되었고 RegisterClientScriptBlock에 등록된 스크립트는 여 <는 양식> 태그 바로 다음에 배치되었습니다. ASP.NET 2.0에서는 둘 다 닫는 </form> 태그 바로 앞에 배치됩니다.
참고
RegisterStartupScript에 함수를 등록하는 경우 클라이언트 쪽 코드에서 명시적으로 호출할 때까지 해당 함수가 실행되지 않습니다.
IsStartupScriptRegistered 메서드를 사용하여 스크립트가 이미 등록되었는지 확인하고 스크립트를 다시 등록하지 않도록 합니다.
기타 ClientScriptManager 메서드
ClientScriptManager 클래스의 다른 유용한 메서드는 다음과 같습니다.
| GetCallbackEventReference | 이 모듈의 앞부분에 있는 스크립트 콜백을 참조하세요. |
|---|---|
| GetPostBackClientHyperlink | 클라이언트 쪽 이벤트에서 다시 게시하는 데 사용할 수 있는 JavaScript 참조(javascript:<call>)를 가져옵니다. |
| GetPostBackEventReference | 클라이언트에서 게시물을 다시 시작하는 데 사용할 수 있는 문자열을 가져옵니다. |
| GetWebResourceUrl | 어셈블리에 포함된 리소스에 대한 URL을 반환합니다. RegisterClientScriptResource와 함께 사용해야 합니다. |
| RegisterClientScriptResource | 웹 리소스를 페이지에 등록합니다. 이러한 리소스는 어셈블리에 포함되고 새 WebResource.axd 처리기에서 처리됩니다. |
| RegisterHiddenField | 숨겨진 양식 필드를 페이지에 등록합니다. |
| RegisterOnSubmitStatement | HTML 양식이 제출될 때 실행되는 클라이언트 쪽 코드를 등록합니다. |