지난 2000년 10월호 컬럼 에서는 새로운 Active Server Pages.NET(ASP.NET) 서버 측 컨트롤이 나오게 된 동기와 그것의 기본 구조를 살펴보았습니다. 이번 달 컬럼에서는 ASP.NET와 컨트롤 상태 관리, 라운드 팁, 데이터 포스팅 등을 포함한 ASP.NET 서버 측 컨트롤, 그리고 작성적 비작성적 컨트롤을 모두 사용하여 보다 풍부한 UI를 개발하는 작업 등에 대해 심층적으로 살펴보고자 합니다.

90년대 중반에는 브라우저의 확장(주로 ActiveX® 컨트롤 및 Java) 언어 애플릿을 통해 풍부하고 동적인 웹 사이트를 만들 수 있었습니다. 불행하게도 이러한 접근은 여러 가지 문제들을 낳았는데, 가장 큰 제약은 모든 클라이언트 사이트가 이러한 기술을 지원하지는 않는다는 점이었습니다. 차세대 장치들이 급속하게 확산되고 있는 현시점에서 그러한 문제는 더욱 커집니다. 더 이상은 하나 또는 두 개의 잘 알려진 클라이언트 환경에만 의존할 수 없게 되었습니다. 즉, 작은 휴대형 장치나 휴대폰에서부터 데스크톱 컴퓨터에 이르기까지 엄청나게 많은 수의 잠재적 장치들이 웹 사이트에 대한 클라이언트가 될 수 있습니다. Microsoft® .NET Framework는 서버에서 사용자 인터페이스 코드를 순수한 HTML(WML 및 XHTML과 같은 보다 새로운 표준들도 포함하여)로 작성하도록 하고, 그 HTML을 브라우저로 표시하도록 함으로써 이러한 문제를 해결합니다. 모든 브라우저가 HTML을 이해하기 때문에 UI 표시를 클라이언트로 보내는 것은 합리적인 방법입니다. .NET 플랫폼의 심장부에는 바로 ASP.NET이 있습니다.

ASP.NET


물론 서버로부터 원시 UI를 생성하는 것은 기본적으로 현재 ASP가 하고 있는 기본적인 작업입니다. ASP 페이지는 서버 측의 다양한 런타임 요소들에 기반하여 HTML을 동적으로 생성합니다. ASP는 일련의 IDispatch 포인터로서 액세스할 수 있는 내부 개체 모델을 갖고 있습니다. 일부 HTML을 클라이언트로 보내기 위해서는 단지 ASP Response 개체(개체의 컨텍스트를 통해 얻을 수 있음)를 포착해서 IResponse::Write를 호출하기만 하면 됩니다. Write 메서드로 보내는 문자열은 클라이언트의 브라우저에 나타나는 것입니다.

ASP는 웹 사이트를 만드는 데 효율적이고 광범위하게 사용되는 수단이지만, 여러 가지 문제점을 갖고 있습니다. 먼저 ASP는 다소 정렬되어 있지 못합니다. ASP 페이지에는 원시 HTML, 스크립팅 코드, COM 개체, 텍스트 등을 포함한 거의 모든 것들이 들어갈 수 있습니다. 이는 페이지의 컨텐트와 그것의 동작 사이에 아무런 형식적 구분이 없다는 것을 뜻합니다. 마치 그 옛날 스파게티 코딩 원칙으로 되돌아간 듯 합니다.(페이지에 일부 코드를 넣고 무슨 일이 생기는지 보십시오.) ASP.NET은 표준 ASP 프로그래밍 모델에 약간의 질서를 도입합니다.

기존 ASP의 두 번째 약점은 VBScript 및 JScript 같은 타입 없는 스크립팅 언어를 사용하게 된다는 것입니다. 타입 점검을 요구하는 다른 스크립팅 엔진을 설치할 수 있지만, 그것들은 VBScript 및 JScript®만큼 잘 알려지고 광범위하게 사용되는 것이 아니며, ASP.NET은 웹 페이지에서 스크립트에 기반한 부분과 그것의 컨텐트를 분명하게 분리합니다.

ASP의 마지막 약점은 웹 페이지에서 무엇인가 하려면, 많은 코드를 작성해야만 한다는 것입니다. 구식의 Windows® 기반 개발자들이라면 선언적 프로그래밍 모델이 훨씬 나은 모델이라는 것을 알고 있을 것입니다.(대화 상자를 설계할 때 손을 사용하는 것과 리소스 편집기를 사용하는 것을 비교해보십시오.) ASP.NET은 웹 프로그래밍에 선언적 모델을 가져옵니다. 즉, ASP.NET 서버 측 컨트롤은 단순히 웹 페이지를 선언하는 것만으로 웹 페이지에 작용합니다. ASP.NET 페이지가 로딩되면, 그것은 ASP 페이지 내에 있는 컨트롤을 나타냅니다. 그 후에 브라우저가 이해할 수 있는 일부 HTML을 만드는 것은 컨트롤이 하는 일입니다.

다른 컨트롤에서의 작성

이번 달에는 작성 컨트롤의 예로서 단순한 화씨 온도/섭씨 온도 변환 컨트롤 또는 다른 표준 컨트롤(목록 상자 및 라디오 단추 등)로 이루어진 서버 측 컨트롤을 사용할 생각입니다. ASP.NET에 포함된 이와 같은 가벼운 컨트롤들이 개발 작업을 간편하게 만들어줄 것입니다. 필자의 경우 온도 변환기 컨트롤은 두 개의 텍스트 상자와 두 개의 누름 단추가 하나의 구성요소로 결합되어 있습니다. Fahrenheit 상자에 숫자를 입력하고 Fahrenheit To Centigrade 단추를 누르면 화씨 온도가 섭씨 온도로 변환됩니다. 또는 Centigrade 상자에 숫자를 입력하고 Centigrade To Fahrenheit 단추를 누르면 섭씨 온도가 화씨 온도로 변환됩니다.
그림?1은 Microsoft Internet Explorer 5.5에서 작동중인 컨트롤을 보여줍니다.



그림 1 온도 변환기 컨트롤 대화 상자


온도 변환기 컨트롤은 C#으로 작성됩니다(Visual Basic으로 더 쉽게 작성해왔지만). 그림?2에는 전체 컨트롤에 대한 코드가 들어 있습니다. 그 다음의 몇 가지 섹션은 코드에 대한 소개로서, 컨트롤의 속성을 유지하는 방법과 주 컨트롤에서 하위 컨트롤에 응답하는 방식을 포함한 주요 측면들을 집중적으로 다룹니다.

속성

하나의 컨트롤이 하는 일은 보통 사용자에게 작은 데이터를 관리할 수 있는 인터페이스를 제공하는 것으로, 이 인터페이스는 일반적으로 컨트롤 내의 속성으로서 표시됩니다. 이 컨트롤은 이중으로 표시되는 두 개의 속성(실제 화씨 온도 및 섭씨 온도)을 유지합니다. C#은 컨트롤의 속성을 관리하기 위해 accessor 및 mutator 함수를 사용합니다. 다음과 같이 단순히 member 변수를 하나의 타입으로 열거하는 대신:

Double m_fFahrenheitValue;
Double m_fCentigradeValue;

C#은 유용한 구문을 제공하여 할당 및 검색 값의 프로세스에 기능을 넣을 수 있도록 합니다. 예를 들어 그림?3의 코드는 accessor 및 mutator 함수를 통한 속성 관리를 위한 C# 구문을 보여줍니다.

온도 컨트롤의 Fahrenheit 및 Centigrade 속성은 get 및 set 함수에 의해 액세스됩니다. 그림?3에 나오는 C# 구문은 컨트롤의 FahrenheitValue 및 CentigradeValue에서 값을 요구할 때 accessor 함수( get 함수)가 호출되도록 합니다. 이 컨트롤은 단순히 실제 화씨 값을 해당 값을 표시하는 텍스트 상자로부터 가져온다는 점을 주목하십시오. 이와 비슷하게 mutator 함수(set 함수)는 값이 컨트롤의 FahrenheitValue 및 CentigradeValue에 할당될 때 호출되어, 새로운 값을 해당 값을 표시하는 텍스트 상자에 저장합니다. 이를 통해 온도 값의 관리가 아주 간편해집니다.

하위 컨트롤

2000년 10월호 컬럼에서 설명한 서버 측 컨트롤은 약간 미흡했습니다.(단지 한 줄의 HTML만이 브라우저로 표시되었습니다.) 어느 기능을 사용하여 컨트롤을 만든다는 것은 다른 요소들(가령 다른 표준 컨트롤)로부터 컨트롤을 작성한다는 것을 의미합니다. ASP.NET 서버 측 컨트롤 프레임워크는 이 기능을 두 가지 방식으로 제공합니다. 즉, 로딩 시간에 하위 컨트롤을 작성함으로써 별도의 하위 컨트롤에서 컨트롤을 작성하거나 또는 ASP.NET 페이지에서 컨트롤을 HTML로 렌더링할 수 있습니다. 이제 런타임 시 하위 컨트롤을 작성함으로써 서버 측 컨트롤을 작성하는 방법에 대해서 알아보기로 하겠습니다.

ASP 페이지가 서버 측 컨트롤을 포함하면, ASP 프레임워크는 서버 측 컨트롤의 CreateChildControls 메서드를 호출합니다. CreateChildControls는 형식에서 하위 컨트롤을 만드는 것을 목적으로 하는 덮어쓸 수 있는 함수입니다. 그림?2의 온도 변환기 컨트롤은 두 개의 LiteralControls, 두 개의 TextBox 컨트롤, 두 개의 단추 컨트롤을 만듭니다. 이러한 웹 컨트롤은 System.Web.UI 이름 공간에서 나옵니다.

그림?2의 코드는 두 개의 LiteralControls(Fahrenheit 및 Centigrade 레이블)를 만들지만, 그것들에 한정되지 않는다는 사실을 주의하십시오. 필자는 LiteralControl의 텍스트를 변경할 계획이 없으므로 이는 상관이 없고, 따라서 레이블을 표시하는 변수에 한정될 이유가 없습니다. 그러나 실제 온도 값을 표시하는 TextBoxes는 TemperatureConverter 클래스의 member 변수라는 점에 주의하십시오. TemperatureConverter 컨트롤은 변수로서의 TextBoxes에 한정되므로 컨트롤에 의해 저장되는 값들은 사용자가 입력한 가장 최근의 값들입니다.

또한 각 하위 컨트롤은 Controls.Add라는 함수를 통해 TemperatureControl의 하위 컨트롤 목록에 추가된다는 점에 주의하십시오.(컬렉션의 이름은 Controls입니다.) 주 컨트롤은 하위 컨트롤을 보유하고, 서버 측 컨트롤은 하위 컨트롤 컬렉션의 실행과 HTML을 통해 그것들을 클라이언트로 렌더링하는 작업을 담당합니다.

단추를 눌렀을 때의 반응

지금까지, 컨트롤에 상태를 추가하는 것과 주 컨트롤이 하위 컨트롤을 만들도록 하는 것을 통해 상당히 멀리까지 왔습니다. 이 컨트롤을 사용하여 ASP.NET 페이지를 요청하면, 그림?1의 대화 상자에 있는 것과 매우 흡사한 것을 보게 될 것입니다. 그러나 사용자가 변환 단추들 중 하나를 누르면 컨트롤이 요청된 버전을 수행함으로써 거기에 응답하기를 바라게 됩니다. 그러므로 누름 단추에 핸들러를 부착할 필요가 있습니다.

ASP.NET 형식에 단추가 추가되면 그 단추의 AddOnClick 메서드를 통해 그 단추에 이벤트 핸들러가 부착됩니다.(베타 버전에서는 달라질 수도 있습니다.) AddOnClick은(System 이름 공간에서 얻어지는) EventHandler 대리인이라는 하나의 매개 변수를 요구합니다. 예를 들어 Fahrenheit To Centigrade 단추는 현재의 섭씨 값을 업데이트하여 현재의 화씨 값을 반영합니다. Fahrenheit To Centigrade 단추를 누르면 일부 코드가 실행되어야 합니다. 온도 변환기의 예에서 Fahrenheit To Centigrade 단추는 단추의 핸들러에 연결된 EventHandler 대리인에 부착됩니다. 핸들러의 임무는 단순히 온도를 하나의 단위에서 다른 단위로 변환하는 것입니다. 다음은 화씨에서 섭씨로 변환하는 데 사용되는 핸들러입니다.

private void F2CConvertBtn_Click(
  Object sender, EventArgs e) {
    CentigradeValue = F2C(FahrenheitValue);
}

화씨에서 섭씨로 변환할 때 F2C에 대한 호출 내에서 FahrenheitValue 속성을 액세스하면 Fahrenheit 텍스트 상자에서 데이터가 얻어집니다. CentifradeValue 속성에 값을 할당하면 섭씨 속성 값이 Centigrade 텍스트 상자에 들어갑니다.

페이지에서의 컨트롤 사용

컨트롤이 어셈블리에 컴파일링되면 그것을 ASP.NET에서 사용할 수 있습니다. 그림?4는 온도 변환기의 인스턴스를 선언하는 일부 ASP.NET 코드를 보여줍니다. ASP.NET 프레임워크가 이 페이지를 로딩하면, ASP.NET은 본문, 중앙, 폰트 태그를 작성합니다. 그런 다음 폼 태그는 서버 측 컨트롤에서 나오는 입력 컨트롤을 관리합니다. 전체 그림을 보려면, 서버 측 컨트롤에서 나오는 HTML을 보십시오( 그림?5 참조).

서버 측 컨트롤에 의해 만들어진 HTML

ASP.NET 서버 측 컨트롤의 기본적인 임무는 브라우저가 처리할 수 있는 일부 마크업 언어를 만드는 것입니다. 그림?5의 서버 측 컨트롤 선언의 위치에 두 개의 레이블과, 숫자 형식의 값을 가진 두 개의 편집 컨트롤과, 데이터를 서버로 보내는 두 개의 누름 단추가 있다는 것에 주의합니다. 서버 측 컨트롤 아키텍처의 장점은 그 라인들을 코드 업할 필요가 없다는 것입니다. 온도 변환기 컨트롤이 필요한 경우에는 언제라도 그림?2에 나오는 온도 변환기 서버 측 컨트롤을 참조할 수 있습니다.

결론

ASP.NET 서버 측 컨트롤 아키텍처는 웹 사이트 작성 및 관리 속도를 엄청나게 향상시켜줍니다. 이러한 변화는 개발자들이 과거에 C와 SDK를 사용하여 Windows 기반 응용 프로그램에서 모든 것을 프로그램해야만 하다가 MFC를 사용하게 된 것과 마찬가지일 것입니다. MFC는 Windows SDK라고 알려진 집합적 프로그래밍 세부내용에 대한 프레임워크를 소개했습니다. 응용 프로그램을 작동시키기 위해 일일이 수동으로 Windows 클래스를 코딩하고 WndProc을 설정하는 대신, MFC는 개발자를 위해 많은 사전 작업을 대신해줍니다. 이와 마찬가지로, 웹 페이지를 움직이게 하기 위해 HTML의 모든 라인을 일일이 작성하는 대신, 기능을 ASP.NET 서버 측 컨트롤에 넘기고 필요할 때마다 그것을 사용하면 됩니다. 이번 달에 필자는 하위 컨트롤로 이루어진 서버 측 컨트롤의 작성에 대해 알아보았습니다. 다음 컬럼에서는 비작성 서버 측 컨트롤, 또는 그것들을 HTML 형태로 클라이언트로 렌더링하는 하위 컨트롤을 관리하는 서버 측 컨트롤에 대해 알아보겠습니다.