SP.NET의 프로그래밍
인터페이스는 서버 페이지 내용을 채우는데 사용할 수 있는 매우 풍부한 컨트롤 프레임워크를 제공합니다. 이
컨트롤들 대부분은 보다 특화된 컴포넌트를 만드는데 사용될 수 있는 수많은 속성, 메서드, 이벤트를 제공합니다.
예를 들어, 최근 이 칼럼에서는 정렬, 페이징, 항목 선택, 열 템플리트, 제자리 템플리트를 포함한
DataGrid 컨트롤이 제공하는 모든 기능을 다루었습니다. DataGrid가 고도로 사용자 지정 가능한
컨트롤이더라도, 이러한 속성들을 사용하면 결과적으로 일반적인 DataGrid보다 훨씬 더 편리한 컨트롤이
됩니다.
 이 모든 코드를 고유한 태그 내에 두는
것도 좋습니다만, 결국 ASPX 파일을 페이지에 한정된 변수, 로직, 클래스, 사용자 정의 함수로 가득 채우게
됩니다. ASPX 페이지는 세 개의 논리적인 요소인 지시자(directive), 코드, 레이아웃으로 구성됩니다.
지시자나 레이아웃은 분명히 어쩔 수 없이 특정 페이지에 묶이게 되지만, 코드는 어느 정도 재사용성을 가질 수
있으며, 동일한 응용 프로그램 또는 심지어 동일한 서버 컴퓨터 상의 다른 응용프로그램 내의 여러 페이지에서
공유되는 클래스, 함수, 컨트롤로 구성될 수도 있습니다.
지난 몇 달 동안 ASP.NET에 대해
글을 써왔으며, 이번 달에는 코드 비하인드(code-behind)라고 불리는 기법을 파헤쳐보고, 프로젝트 관리
및 개발에 미치는 영향을 검토해 보겠습니다. 그런 다음, 사용자 컨트롤이라고 불리는 특별한 범주의 컴포넌트를
살펴볼 것입니다. 사용자 컨트롤은 사용자 정의 컨트롤처럼 보이지만, HTML 및 코드로 이루어진 복합적인 특성
때문에 임베딩 및 프로그래밍 가능한 페이지와 더욱 유사합니다. 마지막으로, ASP.NET 컴포넌트 아키텍처를
마무리하는 사용자 지정 서버 컨트롤을 소개하겠습니다.
코드
비하인드
ASPX 페이지는 Microsoft
.NET에서 소개된 웹 응용 프로그램의 새로운 모델인 웹 폼(Web Form) 페이지의 소스 코드를 나타냅니다.
웹 폼은 Visual Basic과 같은 RAD(rapid application development) 도구에서
유래되었습니다.
Visual Basic에서 폼은 두
개의 개별적인 부분으로 나누어지는데, 하나는 시각적인 컴포넌트 기반 레이아웃이며, 다른 하나는 구성요소 컨트롤과
상호작용하는 코드입니다. 하지만, Visual Basic에서의 이러한 논리적이고 깔끔한 구별은 폼이 디스크에
직렬화될 때 사라져 버립니다. 실제로 코드와 레이아웃 정보가 둘 다 들어간 단일 .frm 파일을 항상 가지게
됩니다. IDE는 코드와 레이아웃을 완전히 독립적인 방법으로 작업할 수 있게 해주지만, 두 사람(말하자면,
프로그래머와 디자이너)이 한번에 동일한 폼에 대해 작업할 수 있게 허용하지 않습니다.
ASP에서는 문제가 더욱 심각합니다. 언어 구조가 레이아웃과 코드를 깔끔하게 분리하는 것을 아예
허용하지 않습니다. 다른 한편, 이 점에 웹 기술로서 ASP가 성공하게 된 열쇠라고 할 수 있습니다. 스크립트와
HTML을 혼합하는 것은 기술 수준이 다양한 사람들이 간단하고, 효율적인 웹 페이지를 쉽게 작성할 수 있게
해주었습니다. ASP.NET은 레이아웃과 코드 요소를 보다 바람직하게 분리할 수 있게 해줍니다.
이전에
언급했듯이, ASPX 페이지에는 세가지 요소(지시자, 레이아웃, 코드)가 있습니다. 지시자는 페이지를 처리하는
컴파일러와 브라우저를 위해 메시지를 삽입합니다. 이 메시지에는 사용하는 언어, 추적 및 상태 유지와 같은 런타임
서비스의 사용 가능 여부를 지정하며, 요구되는 트랜잭션 지원을 지시하고, 지역 코드 페이지 식별자(LCID)와
장애 상황 시 사용자가 리디렉션될 페이지를 지정합니다.
레이아웃은 브라우저가 받기 원하는
템플리트입니다. 일반적으로 HTML 코드이지만, @Page 지시자의 ContentType 특성을 통해 정확한
MIME 형식이 지정될 수 있습니다. 예를 들면, 다음은 XML이 반환될 것임을 지정합니다.
<%@ Page ContentType="text/xml" language="VB" %>
ASP.NET 페이지 지시자에 대한 전체 설명은 @Page에 관한 문서인 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconpagedirectives.asp
를 참조하십시오.
레이아웃의 경우, HTTP 런타임에
의해 처리되는 서버 컨트롤은 브라우저를 위한 출력을 생성하는데 사용될 수 있습니다. 서버 컨트롤은 함수나 메서드
호출(CreateObject와 같은)을 통해 인스턴스화 되는 것이 아니라 사용자 지정 또는 시스템이 제공하는
네임스페이스에 속한 마크업 태그를 통해 선언적으로 삽입됩니다.
선언적 프로그래밍에서는, 특성을
설정하여 컨트롤을 구성합니다. 이것으로도 대부분의 요구사항을 만족시키지만, 고도로 상호작용하는 페이지의 경우
일반적으로 서버 컨트롤에 대한 코드를 작성해야 합니다. 이 코드는 웹 폼과 상호작용할 수 있게 해주는 사용자
인터페이스 로직으로 구성됩니다.
코드 비하인드는 ASPX 파일에
지시자와 페이지 레이아웃을 저장하고, 페이지 뒤에 있는(페이지를 처리하는) Visual Basic이나 C#
코드를 별도의 파일에 저장할 수 있게 해주는 ASP.NET 기능입니다. 코드 비하인드 파일에 대한 링크는
@Page 지시자의 특성으로 유지됩니다. 사용자가 브라우저에서 ASPX 페이지를 요청하면, 코드 비하인드 클래스
파일이 실행되고 동적으로 페이지의 출력을 생성합니다. 페이지가 호출될 때, 코드 비하인드 파일이 로드되며,
페이지에 통합된 부분으로 다루어집니다.
위 내용이 어떻게 구현되고, 실제로
어떻게 동작하는지 세부사항을 깊이 파고 들기 전에, 이러한 접근방법의 실용적인 이점을 먼저 강조하도록
하겠습니다. 웹 폼 개발에는 두 개로 나누어진 사람 그룹(디자이너와 프로그래머)을 연관시킬 수 있습니다.
페이지의 구조가 정의되면 구성요소 서버 컨트롤의 개수, 이름, 형식에 기초하여, HTML 디자이너는 ASPX
파일을 가져와서 가능한 한 친숙하고 멋지게 꾸밉니다. 디자이너는 다양한 컨트롤의 위치, 색상, 글꼴, 클라이언트
스크립팅을 결정합니다. 동일한 시점에 Visual Basic과 C#으로 작업하는 프로그래머는 페이지가 제대로
동작하고 사용자의 기대를 충족시키는데 필요한 코드와 대리자를 개발합니다.
이러한 접근방법은
Visual Basic 6.0에서 사용했던 폼 개발과 동일하지만, 레이아웃과 코드 간에 물리적인 분리를 도입할
수 있게 해줍니다.
코드 비하인드 사용
코드 비하인드 기능을 사용 가능하게
하려면 @Page 지시자에 두 개의 특성을 추가합니다.
<%@ Page Language="VB"
Inherits="StdPageClass"
Src="StdPage.vb" %>
@Page 지시자는 .aspx 파일당 하나씩만 가질 수 있습니다. 공백으로 구분된 리스트를 통해
여러 개의 특성이 정의되며, = 기호 주위에는 공백을 쓰면 안됩니다.
Inherits 특성은 상속받을
페이지를 위한 코드 비하인드 클래스를 나타내며, Page 클래스로부터 상속된 클래스의 이름이 될 수 있습니다.
코드 비하인드 특성(CodeBehind)은 컴파일할 코드 비하인드 클래스 코드를 가지고 있는 소스 파일의
URL입니다. 그 후 ASPX 페이지는 .aspx URL을 통해 브라우저에 보이게 되는 컴파일된 코드로
저장됩니다.
HTTP 런타임 모듈에 이 ASPX 페이지가 지정되면, @Page 지시자를 분석합니다.
CodeBehind가 존재하면, 지정된 코드 비하인드를 로드합니다. 다음으로, 성공적으로 컴파일이 된 후
HTTP 런타임은 Inherits 지시자의 내용을 활용하여 현재 페이지의 인스턴스를 만드는 클래스의 이름을
가져옵니다. 실제로 브라우저를 통해 표시되는 ASPX 페이지는 .NET Framework의 Page 클래스로부터
파생된 클래스의 실행 중인 인스턴스로 웹 서버 상에서 보여집니다. 코드 비하인드를 사용하지 않으면,
<script runat="server"> 태그 내에 삽입한 소스 코드는 private 메서드나
Page 클래스의 특정 인스턴스를 재정의한 것으로 간주됩니다. 이와 달리 코드 비하인드 접근방법을 선택하면,
페이지의 기본 클래스를 제어할 수 있으며 이 전에 작성한 클래스로부터 자동적으로 상속받게 만들 수
있습니다.
또한 Inherits 특성은 특정 네임스페이스에 있는 사용자 지정 클래스를 가리킬 수도
있습니다.
<%@ Page Language="C#"
Inherits="MyDotNetLib.StdPageClass"
Src="StdPage.cs" %>
이 경우, StdPage.cs 파일은 다음과 같을 것입니다.
namespace MyDotNetLib {
using System;
using System.Collections;
using System.Data;
using System.Web.UI;
using System.Web.UI.WebControls;
public class StdPageClass : Page {
}
}
클래스와 작업할 수 있는 기능은 단순히 <script> 태그 내에 있는 프로시저
외부에 선언하는 것보다 멋지고 효율적인 방법으로 public 데이터 멤버를 선언하고 만들 수 있게 해줍니다.
클래스의 전역 멤버를 만들어서 표시 범위(visibility)를 보다 잘 제어할 수 있습니다. 뿐만 아니라,
Page로부터 이미 상속받은 기존 하위 클래스로부터 시작하는 코드 비하인드 클래스를 정의할 수 있습니다.
Page 또는 Page 기반 클래스로부터 상속받을 때, Windows Form의 근간인 시각적인
상속(visual inheritance)라고 불리는 멋진 기능을 이용하게 됩니다.
단순한 메서드 및 변수
선언 목록 대신에 Page 파생 클래스를 명시적으로 작성해야 한다는 사실을 제외하면, 일반 ASPX 페이지와
코드 비하인드 페이지 간에는 별다른 차이점이 없습니다. 페이지가 맨 처음으로 불려질 때, 코드 비하인드인
경우에는 코드 생성기 클래스가 Src 특성으로부터 읽은 소스 파일로부터 자기 자신을 초기화합니다. 코드
비하인드가 아닌 경우에는 <script> 태그에서 추출된 문자열을 사용해서 생성됩니다. 어느 경우이든
사용자는 차이점을 느끼지 못할 것입니다.
코드 비하인드 페이지를 위한 코드를
작성할 때, 한가지 중요한 점을 알아야 합니다. 레이아웃에 runat="server"로 선언한 컨트롤은 페이지
클래스의 protected 또는 public 멤버로 선언한 이후에만 안전하게 접근할 수 있습니다. 예를 들어
다음과 같은 두 개의 텍스트 상자가 있는 경우,
<asp:textbox id="fname" runat="server" />
<asp:textbox id="lname" runat="server" />
코드 비하인드 클래스에서 텍스트상자들의 ID를 그냥 쓸 수는 없습니다. 대신에 이들을
protected 또는 public 클래스 멤버로 먼저 선언해야 합니다.
protected TextBox fname, lname;
그림
1 에서는 기본 값이 stdpage.cs의 OnLoad 재정의 내에서 설정된 두 개의 텍스트 상자로 된
최소한의 코드 비하인드 페이지의 소스 코드를 볼 수 있습니다. 실제 페이지는
그림 2에서 볼 수 있습니다.
그림 2 코드 비하인드 페이지
A
href="javascript:OpenUrl('figures.asp#fig1');" class="clsFigs"
TARGET="_self"> 그림 1에서는 부모 클래스의 동일한 메서드를 호출할 수 있게 해주는
base 키워드의 역할을 알 수 있습니다.
base.OnLoad(e)
예제 코드에서 두 개의 텍스트 상자는 읽기 전용입니다. 컨트롤을 읽기 전용으로 만들고 싶으면
ReadOnly 속성을 true로 설정합니다.
fname.Attributes["readonly"] = "true";
lname.Attributes["readonly"] = "true";
이제, 사용자가 텍스트 상자의 내용을 편집하고 서버로 전송할 수 있게 해주는 새로운 페이지를
만들려고 한다고 가정해 봅시다. 코드 비하인드를 사용하는 경우에는 클래스 상속 덕택에 쉽게 처리가 가능합니다.
그림
3 에서는 myeditpage.aspx라는 새로운 페이지의 레이아웃으로 된 ASPX 파일을 볼 수
있습니다. 이 페이지는 버튼과 편집 가능한 텍스트상자를 가집니다. 버튼이 클릭되면, 코드 비하인드 클래스에
정의된 OnEdit 프로시저를 실행합니다.
<% @ Page Language="C#"
Inherits="MyDotNetLib.EditPage"
Src="EditPage.cs" %>
Editpage.cs에 정의된 EditPage라는 새로운 클래스로부터 페이지를 파생시킬 수
있습니다. 이 클래스는 StdPage로부터 상속받아서, 응용 프로그램 내에 진정한 페이지 클래스 계층 구조를
만들 수 있습니다.
public class EditPage : MyDotNetLib.StdPage {
protected Button btnEdit;
protected Label statusbar;
•••
}
그림
4 는 EditPage 클래스의 소스 코드를 보여줍니다. 이 클래스는 StdPage로부터 상속되어
fname 및 lname 텍스트 상자에 자유롭게 접근하며, 버튼의 클릭 이벤트 처리기를 정의합니다. 이 코드가
동작하게 하려면, StdPage의 컴파일된 버전이 웹 서버의 Bin 디렉터리나 응용 프로그램의 Bin 디렉터리
내에 있어야 합니다. 다음 명령은 stdpage.cs를 DLL 어셈블리로 컴파일합니다.
csc /t:library /r:system.web.dll /r:system.dll stdpage.cs
그림 5는 데모 페이지의 출력 결과를 보여줍니다.
그림 5 동작 중인 EditPage
코드 비하인드는 보다 모듈화된 코드를
작성할 수 있게 해주도록 디자인된 재미있는 기법입니다. 코드 비하인드의 주요 목표는 코드와 레이아웃을 물리적으로
분리할 수 있게 해주는 것입니다. 이를 위해서는 .NET Framework의 개체 지향 특성을 이용하여 보다
특화된 기능을 제공하는 페이지 클래스의 계층 구조를 만들 수 있습니다. 조작하는 모든 개체는 Page 클래스에서
상속된 것이며, Page가 특화되고 사용자 지정된 인스턴스이어야 합니다. 결과적으로 코드 비하인드를 사용하여
모듈화와 어느 정도의 페이지 레벨 재사용성을 얻을 수 있습니다. 하지만 불행하게도 레이아웃을 재사용할 수 있는
방법은 없습니다. 이전에 정의한 클래스로부터 코드 비하인드 클래스를 파생시킬 수 있지만, 두 페이지의 레이아웃은
완전히 독립적인 존재입니다.
내장 가능한
폼
페이지릿(Pagelet)은 또 다른
수준의 페이지 재사용성을 제시하며, 사실 더욱 정교하기 때문에 재사용성이 보다 높습니다. 페이지릿을 사용하여
폼(페이지가 아니라)은 재사용성의 단위가 됩니다. 페이지릿은 내장 가능한 폼처럼 보일 수 있습니다. 페이지릿을
웹 폼과 동일한 방법으로 정의한 후, 이름을 부여해서 컴포넌트처럼 취급합니다. DHTML 스크립트릿과
친숙하다면, 페이지릿을 ASP.NET에서의 스크립트릿으로 생각하면 됩니다.
하지만 폼과는 달리
페이지릿은 지정된 네임스페이스와 태그 이름을 통해 ASP.NET 페이지로 가져와서 사용하는 시각적인
컴포넌트입니다. 말하자면, 다른 표준 .NET 서버 컨트롤처럼 페이지릿을 선언하고 페이지릿이 제공하는 속성과
메서드를 사용하여 코드를 작성합니다.
페이지릿은 독립적인 ASP.NET
페이지처럼 작성하며, 레이아웃과 코드 블록을 완성해야 합니다. 레이아웃은 폼을 만드는 컨트롤인 컴포넌트의 사용자
인터페이스를 나타냅니다. 내부 코드는 다양한 내부 컨트롤과 함께 묶여서 비즈니스 로직을 구현합니다. 다음은
간단한 페이지릿 예제입니다.
<script language="C#" runat="server">
public String Color = "blue";
public String Text = "Message User Control!";
</script>
<span id="Message"
style="color:<%=Color%>"><%=Text%>
</span>
이 코드는 .ascx 확장자를 가진 파일로 저장됩니다. <script> 태그의 내용은
컴포넌트의 프로그래밍 인터페이스와 내부 코드를 모두 정의합니다. public으로 정의된 모든 것은 컨트롤 외부로
보여지며, 클라이언트에 의해 외부적으로 호출될 수 있습니다.
코드의 HTML
부분(<%...%>> 블록 때문에 ASP처럼 보이는)은 컨트롤의 사용자 인터페이스입니다. 이것은
pagelet 선언의 결과로 호스트 페이지 내에 삽입되는 출력을 만들어냅니다.
사용하기 위해, 페이지릿은
ASPX 페이지 내에 먼저 등록되어야 하며, @Register 지시자를 통해 수행됩니다.
<%@ Register
TagPrefix="expo" TagName="Message"
Src="pagelet.ascx" %>
TagPrefix와 TagName 특성은 페이지 내에서 컨트롤을 식별할 네임스페이스 접두사와 태그
이름을 가리킵니다. 이 경우에는 다음과 같습니다.
<expo:Message>
Src 특성은 페이지릿의 소스 코드를 가리킵니다. 그림
6 은 그림 5에서 본 ASP.NET 페이지에서
페이지릿을 사용 가능하도록 한 버전을 보여줍니다. 페이지릿은 ASP와 유사한 문법을 사용하여 내부 코드에서
public하게 호출가능한 속성과 메서드를 사용합니다. 예를 들어, 사용자가 페이지릿의 Color 속성을 붉은
색으로 설정하려면, 코드는 스타일 태그 내의 속성 값을 다음과 같이 바꿉니다.
... style="color:<%=Color%>">
속성 태그가 실제 값으로 대치되면, 태그는 다음과 같이 보입니다.
... style="color:red">
생긴 것과는 달리 이 코드는 더 이상 ASP가 아닙니다. <%...%> 기호는 단순히
데이터 바인딩되는 코드를 식별하는 것입니다. 이 바인딩은 컨트롤과 데이터 원본 간이 아니라 컨트롤과 컨테이너
환경 간에 이루어지는 것입니다.
사용자 컨트롤
약간의 변경으로 사실상 웹 폼은
페이지릿 사용자 컨트롤 내에 캡슐화될 수 있으며, 그에 따라 다른 페이지 내에 내장할 수 있는 컴포넌트가
됩니다. 페이지릿은 웹 응용 프로그램 간에 단순하고 공통적인 사용자 인터페이스 기능을 모듈화하고 재활용하는 쉬운
방법을 제공합니다. 페이지릿은 사용하기 전에 컴파일되며, 만료되거나 변경이 일어나기 전까지 서버에 계속
캐시됩니다.
ASP.NET 페이지를 처리하는 시스템 컴포넌트인 HTTP 런타임 모듈이 페이지릿을 마주치면,
파일 이름과 확장자에 기초한 이름으로 래퍼 클래스를 즉시 생성합니다. Message.ascx의 경우, 클래스
이름은 ASP.message_ascx입니다.
그렇다면 작성한 웹 폼을 가져다가
사용자 컨트롤로 변경시키려면 어떻게 해야 할까요? 먼저, 페이지릿이 <html>,
<body>, <form> 태그를 가지지 않게 합니다 페이지릿은 자신을 호스팅하는 웹 폼의
레이아웃으로 병합되므로, 이러한 태그는 중첩 문제를 일으킬 수 있습니다. 포스트백 이벤트를 이용하고자 하는
컨트롤만이 실제로 <form runat="server"> 태그 내에 둘러싸여야 한다는 것을
명심하십시오. 더욱이 페이지릿으로 변환하고자 하는 페이지가 @Page 지시자를 가지면, @Control 지시자로
바꾸지 않으면 HTTP 런타임이 오류를 발생시킵니다. 원하지 않는 HTML 태그를 제거했으면, .ascx
확장자로 파일 이름을 바꿉니다. 이것이 파일을 특별히 취급하게 하는 열쇠입니다.
@Control 지시자는
Trace 및 OutputCache라는 두 가지 특성을 지원하지 않는다는 것을 제외하고는 @Page 지시자만큼
강력합니다. 이것이 별로 나쁜 소식은 아닙니다. 만약 추적이 필요하면, 페이지 수준에서 사용 가능하게 지정하기만
하면 자동적으로 페이지릿에도 적용됩니다. 페이지의 캐시 정책을 제어하고 싶으면, 역시 페이지 수준에서 할 수
있습니다. 페이지의 각 부분에 다른 캐시 정책을 가질 수는 없습니다.
페이지릿에 @Control 지시자를
설정할 수 있는 기능은 페이지릿과 호스팅 페이지를 작성하는데 서로 다른 언어를 사용할 수 있게 해줍니다. 예를
들어 페이지릿에서는 Visual Basic을, 호출하는 페이지에서는 C#을 사용할 수 있습니다. Message
페이지릿은 다음 코드와 같이 Visual Basic으로 다시 작성될 수도 있으며, C# 페이지 내에서 여전히
작동됩니다.
<% @ Control Language="VB" %>
<script runat="server">
public Color As String = ""
public [Text] As String = ""
</script>
<span style="color:<%=Color%>"><%=[Text]%> </span>
Visual Basic에서는 사용자 속성으로 만들고 싶을 때 Text 단어를 [ ]으로 둘러써야
한다는 것에 주의합니다. Visual Basic .NET에서는 Text가 예약어(Option Compare 문에
속함)이기 때문입니다.
사용자 지정 서버 측 컨트롤
.NET Framework는 상속을
사용하는 개체 지향 프로그래밍 원칙에 따라 새로운 클래스를 작성하게 해주는 클래스 계층 구조입니다. 여러분은
새로운 클래스를 작성하고 기존 클래스의 동작과 인터페이스를 상속하게 할 수 있습니다(다중 클래스 상속은
.NET에서는 허용되지 않지만, 클래스는 필요한 만큼 인터페이스를 구현할 수 있습니다).
응용
프로그램 간에 공유하고 싶은 함수가 있는 경우, 새로운 클래스를 작성하는 것보다 쉬운 것은 없습니다. 이것은
.NET과 OOP의 기능 중 하나일 뿐입니다. 하지만 ASP.NET의 경우에는 코드 비하인드 클래스, 페이지릿,
일반 클래스 외에 또 하나의 흥미로운 가능성인 서버 컨트롤을 가집니다. ASP.NET 페이지는 폼에 선언적으로
두고 코드를 통해 서로를 묶는 컴포넌트인 서버 컨트롤들로 구성됩니다.
System.Web.UI.WebControls 네임스페이스가 수많은 클래스를 제공하지만, 때로는 자신이 직접
작성할 필요가 있을 수도 있습니다. 서버 컨트롤과 페이지릿의 차이점은 무엇일까요? 사용자 정의된 서버 측
컨트롤은 Control 클래스 계보에 위치한 명시적인 클래스입니다. 반대로 페이지릿은 클래스처럼 취급되지만,
프레임워크의 일부로 작성되어서 제공되는 것이 아닙니다.
더욱이 서버 컨트롤은 내장 사용자
인터페이스를 가지지 않습니다. 컨트롤 소스는 레이아웃과 코드 영역으로 분할되지 않습니다. 페이지릿은 다른
페이지에 내장된 페이지처럼 보이며, 컨트롤처럼 취급됩니다. 이와는 달리, 서버 컨트롤은 서버 컨트롤은
ASP.NET 페이지 내에서 동작되도록 특별히 디자인된 .NET 클래스입니다. 이것은 ASP.NET 서버
컨트롤이 상속되는 방법에서 비롯되는데, Control 클래스를 기본 클래스로 사용합니다. 이것은 웹 폼에 포함된
기능도 역시 상속한다는 것을 의미합니다.
그림
7 의 코드는 TextBox 컨트롤부터 만들어진 매우 간단한 컨트롤을 예로 들고 있습니다. 빈 버퍼
대신에 기본 문자열을 표시한다는 점에서만 부모 개체와 다를 뿐입니다. 이 컨트롤은 TextBox가 적합한
곳에서는 어디서나 사용될 수 있으며, 보다 특화된 컨트롤을 만들기 위한 출발점으로 사용될 수
있습니다.
ASP.NET 페이지에서 컨트롤을 호스트하려면, @Register 지시자를 사용합니다(그림 8 참조). 파생된 컨트롤은 CssClass와 runat 지시자를 포함한
기본 클래스의 모든 속성과 메서드를 자동적으로 지원합니다.
페이지릿은 사용하기 전에 컴파일될
필요는 없습니다. 하지만 컨트롤은 명시적으로 라이브러리로 컴파일되어서 웹 서버의 Bin 디렉터리에 있어야
합니다. 서버 컨트롤에 대한 보다 자세한 사항은 MSDN Magazine의 2000년 10월호 (영문) 와 2001년 1월호 (영문) 의 Visual Programmer 칼럼을
참조하십시오.
다음달 예고
Dino에 대한 질문이나 의견은 cutting@microsoft.com
로 보내십시오.
|
.jpg){kind=small}
