다음을 통해 공유


1장: "Longhorn" 애플리케이션 모델

 

소개

1장: "Longhorn" 애플리케이션 모델

브렌트 렉터
와이즈 올빼미 컨설팅

2003년 10월

목차

"Longhorn" 애플리케이션 모델의 기능
애플리케이션 클래스
NavigationApplication 클래스
XAML(Extensible Application Markup Language)
요약

새 애플리케이션 모델이 필요한 이유는 무엇인가요? 한 가지 주요 이유는 Microsoft® Windows®용 애플리케이션 개발과 웹용 애플리케이션 개발 간의 격차를 해소하기 위한 것입니다.

현재 Windows 애플리케이션을 작성할 때 Windows 기능을 활용할 수 있습니다. 애플리케이션은 풍부하고 응답성이 뛰어난 사용자 인터페이스를 제공할 수 있습니다. 클라이언트 컴퓨터에 애플리케이션을 설치하여 네트워크 연결 없이 애플리케이션을 오프라인으로 실행할 수 있습니다. Windows 애플리케이션은 클라이언트 컴퓨터의 하드웨어 기능을 활용할 수 있습니다.

그러나 기존 Windows 애플리케이션에는 여러 가지 단점이 있습니다. 일반적으로 Windows 애플리케이션을 설치해야 합니다. 이렇게 하면 애플리케이션 및 모든 업데이트를 배포하기 어렵게 만듭니다. Windows 애플리케이션은 브라우저에서 실행되지 않습니다. 따라서 페이지 지향 애플리케이션, 한 페이지에서 다른 페이지로 직접 탐색, 페이지 기록 등과 같은 친숙한 웹 UI 패러다임은 처음부터 만들지 않는 한 애플리케이션에서 사용할 수 없습니다. Windows 애플리케이션은 특히 같은 페이지에서 텍스트와 그래픽을 혼합하려고 할 때 텍스트를 잘 지원하지 않습니다. 그래픽 주위에 텍스트를 자동으로 전달하고 사용자가 시작한 창 크기 변경 내용과 글꼴 및 가독성에 대한 사용자 기본 설정에 응답하는 Windows 애플리케이션을 만드는 것은 엄청난 작업입니다.

웹 애플리케이션에는 고유한 강점도 있습니다. 웹 페이지로 이동하면 브라우저에서 해당 페이지와 페이지에 필요한 구성 요소만 다운로드합니다. 새 페이지로 이동하면 브라우저에서 새 페이지의 요구 사항을 다운로드합니다. 즉, 브라우저는 필요에 따라 애플리케이션을 점진적으로 다운로드합니다.

웹 애플리케이션 배포는 간단합니다. 어떤 배포인가요? 필요한 애플리케이션 구성 요소를 서버에 배치하면 브라우저에서 필요에 따라 다운로드합니다. 배포는 없습니다.

웹 애플리케이션에 대한 UI를 만드는 것도 매우 쉽습니다. 태그를 사용하여 의도를 선언합니다. 예를 들어 특정 위치에 테이블을 사용하려는 경우를 가정해 보겠습니다. 이미지가 테이블을 따라가기를 원합니다. 이미지 주위에 텍스트가 흐르기를 원합니다. 웹 애플리케이션에서 텍스트, 그래픽 및 미디어(소리 및 비디오)를 혼합하는 것은 간단합니다.

물론 웹 애플리케이션에도 나쁜 점이 있습니다. 데스크톱 시스템에 웹 애플리케이션을 설치할 수 없습니다. 따라서 애플리케이션을 오프라인으로 실행할 수 없습니다. 항상 서버에 연결해야 합니다. 특정 애플리케이션 작업에는 서버에 대한 왕복이 필요하며 성능이 저하됩니다. 웹 응용 프로그램 컨트롤 선택은 사용 가능한 Windows 컨트롤에 비해 매우 기본적입니다. 따라서 웹 애플리케이션은 일반적으로 대화형 작업이 좋지 않습니다. 테이블을 사용하여 사소한 레이아웃을 표현해야 하므로 웹 애플리케이션에 대한 매력적인 UI를 개발하기도 어렵습니다.

현재 새 애플리케이션을 디자인하는 개발자는 초기적이고 거대하며 돌이킬 수 없는 결정을 내려야 합니다. 애플리케이션은 웹 스타일 애플리케이션 또는 클래식 Microsoft Win32® 애플리케이션이어야 하나요? 선택하는 애플리케이션 모델에 따라 완전히 별도의 프로그래밍 모델(및 기술!)이 필요합니다.

"Longhorn"을 사용하면 두 세계의 최고를 사용하여 애플리케이션을 개발할 수 있습니다. "Longhorn" 애플리케이션 모델은 웹 애플리케이션의 최상의 기능과 Windows 애플리케이션의 최상의 기능을 사용하고 관리 코드에 따라 단일 통합 프로그래밍 모델로 결합합니다.

새 애플리케이션 모델을 개발하는 두 번째 주요 이유는 현재 사용 중인 다양한 "애플리케이션"을 만들 수 있는 단일 프로그래밍 모델을 제공하기 위한 것입니다. CNN 또는 MSNBC와 같이 즐겨 찾는 웹 사이트 중 하나를 살펴보세요. 웹 사이트가 기존 애플리케이션인가요? 문서인가요? 멀티미디어 프레젠테이션인가요? 대부분의 경우 대답은 세 가지 질문 모두에 '예'입니다.

웹 사이트에 목록 상자, 편집 컨트롤 및 라디오 단추와 같은 UI 요소가 포함된 경우 UI를 표시하는 애플리케이션처럼 보입니다. 그러나 이미지 주위에 흐르는 이미지와 텍스트를 표시하는 경우 웹 사이트는 문서와 유사합니다. Flash 콘텐츠, 그래픽, 오디오, 비디오 및 애니메이션을 표시하면 웹 사이트가 멀티미디어 프레젠테이션인 것 같습니다.

물론 이러한 풍부한 웹 사이트는 개발하기가 어렵습니다. 페이지에 대한 HTML 태그 기반 설명, 풍부한 UI에 대한 Microsoft ActiveX® 컨트롤, 포함된 플래시 애니메이션 및 문서 지원을 위해 PDF(이식 가능한 문서 형식)를 함께 패치해야 합니다. 이러한 모든 기술은 다른 아키텍처를 사용하고, 다양한 성능 특성을 제공하며, 다른 프로그래밍 모델 및 도구가 필요합니다.

일반적으로 애플리케이션의 각 부분을 개발하려면 서로 다른 기술 집합을 가진 여러 개발자를 고용해야 합니다. 그런 다음 개발자는 다른 모델을 단일 작업 애플리케이션에 병합해야 합니다. 애플리케이션 개발은 충분히 어렵습니다. 디버깅하는 것은 종종 악몽입니다.

"Longhorn"은 문서, 애플리케이션 및 미디어의 세 가지 계층을 지원하는 통합 아키텍처를 제공합니다. 태그를 사용하여 선언적으로 UI를 만들겠습니까? 그것을 위해 이동합니다. 풍부한 Windows 컨트롤을 사용해야 합니까? 그런 다음 그렇게! 강력한 형식의 관리되는 언어로 이벤트 처리기를 작성하시겠습니까? 그렇게 할 수도 있습니다. 문서의 텍스트, 그래픽 및 비디오를 사용자의 기본 설정에 따라 지능형 레이아웃 및 프레젠테이션과 혼합하고 클라이언트 시스템에서 가장 잘 보고 읽을 수 있도록 최적화하시겠습니까? 무엇을 추측? 당신도 그것을 얻을.

"Longhorn" 애플리케이션 모델을 사용하면 애플리케이션 스타일 UI 기능, 텍스트 및 그래픽의 문서 스타일 프레젠테이션 및 다양한 미디어 통합을 지원하는 단일 프로그래밍 모델을 사용하여 애플리케이션을 작성할 수 있습니다. 또한 웹 애플리케이션과 같은 태그를 사용하여 UI를 만들 수 있습니다. 또한 웹 애플리케이션의 배포(또는 배포 부족)가 용이합니다. 그러나 Windows 애플리케이션과 같이 오프라인으로 사용하기 위해 애플리케이션을 설치하는 성능과 기능이 여전히 있습니다. 애플리케이션은 하나의 소스 코드 베이스를 다시 컴파일하여 독립 실행형 애플리케이션으로 실행되거나 웹 브라우저에서 호스트할 수 있습니다. 두 경우 모두 애플리케이션은 기존의 많은 Windows 애플리케이션과 마찬가지로 양식 기반이거나 웹 애플리케이션과 같은 페이지 기반일 수 있습니다.

"Longhorn" 애플리케이션 모델의 기능

"Longhorn" 애플리케이션 모델은 애플리케이션이 무엇인지 정의합니다.

  • 진입점
  • 제어 흐름 - 한 페이지에서 다른 페이지로 이동하는 방법
  • 공유 상태 및 리소스
  • 애플리케이션 전체 이벤트
  • 다른 애플리케이션에서 격리

"Longhorn" 애플리케이션 모델은 애플리케이션을 배포하고 유지 관리하는 방법을 정의합니다.

  • 단일 또는 여러 파일로 배포
  • 업데이트, 롤백 및 관리

"Longhorn" 애플리케이션 모델은 애플리케이션에 대한 사용자의 환경을 정의합니다.

  • 제로 임팩트 설치
  • 독립 실행형(Windows 스타일) 또는 브라우저에 통합
  • 온라인 또는 오프라인으로 실행
  • 탐색 모델

"Longhorn" 웹 애플리케이션

"Longhorn" 애플리케이션 모델을 사용하면 오늘날의 웹 애플리케이션을 작성하는 방식과 비슷하게 풍부한 애플리케이션을 작성할 수 있습니다. 이는 작성하는 코드가 DHTML(동적 HTML) 웹 페이지의 코드와 유사하기 때문에 웹 개발자에게 쉬운 마이그레이션 경로를 제공합니다. 태그와 스크립트를 같은 파일에 배치할 수 있습니다(떨림). 애플리케이션에 대한 파일을 웹 서버에 배포할 수 있습니다. 애플리케이션 페이지는 웹 브라우저에서 실행됩니다.

그러나 "Longhorn" 웹 스타일 애플리케이션의 개체 모델은 DHTML보다 훨씬 간단하고 강력합니다. 애플리케이션 코드는 전체 "Longhorn" 프레젠테이션 계층을 사용할 수 있습니다. 따라서 "Longhorn" 웹 애플리케이션은 풍부한 클라이언트 컨트롤을 사용하고, 페이지에서 멀티미디어 및 그래픽을 지원하고, 로컬에서 이벤트를 처리할 수 있습니다. 기본적으로 일반 클라이언트 애플리케이션에서 수행할 수 있는 모든 작업입니다. 실제로 "Longhorn" 웹 애플리케이션은 파일이 서버에 있는 것 외에는 "Longhorn" 데스크톱 애플리케이션과 크게 다르지 않습니다. 브라우저는 일반적으로 UI를 호스트하지만 반드시 호스트하는 것은 아닙니다. 사용자가 클라이언트 시스템에 설치하지 않았기 때문에 애플리케이션이 제한된 권한으로 실행됩니다.

"Longhorn" 데스크톱 애플리케이션

"Longhorn" 애플리케이션 모델은 데스크톱 애플리케이션을 작성하는 방법도 정의합니다. "Longhorn"데스크톱 애플리케이션 사용자가 로컬로 설치한 애플리케이션입니다. 이러한 애플리케이션은 온라인 또는 오프라인으로 실행할 수 있습니다. 이러한 애플리케이션은 셸에 등록하고, 아이콘을 바탕 화면에 배치하고, 시작 메뉴에 바로 가기를 추가하는 등의 작업을 수행할 수 있습니다.

데스크톱 애플리케이션은 브라우저 창 또는 독립 실행형 창에서도 실행할 수 있습니다. 실제로 데스크톱 애플리케이션은 다음을 포함하여 일반적으로 웹 애플리케이션과 연결된 많은 기능을 지원할 수 있습니다.

  • 외부 진입점을 명시적으로 정의합니다. 즉, 모든 페이지에서 시작할 수 있습니다.
  • 페이지 간에 상태 공유
  • 페이지 탐색 이벤트를 비롯한 다양한 이벤트 처리
  • 애플리케이션 흐름 제어
  • 페이지 기록/여행 탐색 로그에서 항목 추가/제거
  • 애플리케이션 창 시작

"Longhorn" 애플리케이션 빌드

"Longhorn" 애플리케이션을 빌드하려면 애플리케이션에 대한 개체 모델을 정의합니다. 코드를 작성하거나 XAML(Extensible Application Markup Language)이라는 언어로 태그를 작성하여 선언적으로 모델을 정의할 수 있습니다. 코드 및/또는 태그를 하나 이상의 .NET 어셈블리, 애플리케이션 매니페스트 파일 및 배포 매니페스트 파일로 컴파일합니다.

필요에 따라 애플리케이션을 컨테이너새 파일 형식으로 패키지할 수 있습니다. 컨테이너의 애플리케이션 파일은 압축, 암호화 및 디지털 서명될 수 있습니다.

2장에서 "Longhorn" 애플리케이션 빌드에 대해 자세히 설명하지만, 지금은 "Longhorn" 애플리케이션을 빌드하면 애플리케이션의 코드, 애플리케이션에서 사용하는 모든 구성 요소를 설명하는 애플리케이션 매니페스트 및 애플리케이션을 설치하고 유지 관리하는 방법을 시스템에 알려주는 배포 매니페스트가 제공됩니다.

"Longhorn" 애플리케이션 배포

"Longhorn" 애플리케이션 모델은 애플리케이션의 쉽고 비용 효율적인 배포를 제공합니다. 가장 간단한 경우 애플리케이션 파일을 서버에 복사하기만 하면 됩니다. 마찬가지로 애플리케이션을 설치하는 것은 간단하고 영향을 주지 않습니다.

한 가지 옵션은 애플리케이션을 전혀 설치하지 않는 것입니다. 사용자는 서버에서 애플리케이션 매니페스트로 이동하여 실행할 수 있습니다. "Longhorn"은 애플리케이션을 증분 방식으로 다운로드하여 실행합니다. 확인 요구 사항, 재부팅 요구 사항 및 DLL 지옥이 없습니다. 실제로 애플리케이션을 설치하거나 실행하는 데 관리자 권한이 필요하지도 않습니다.

또는 사용자가 서버에서 애플리케이션의 배포 매니페스트로 이동하여 실행할 수 있습니다. "Longhorn"은 애플리케이션을 증분 방식으로 다운로드하고, 설치하고, 실행합니다. 기본적으로 모든 "Longhorn" 애플리케이션은 SEE(보안 실행 환경)라는 제한된 권한 환경에서 실행됩니다.

SEE에서 실행되는 애플리케이션은 인터넷 영역과 연결된 오늘날의 애플리케이션에 부여된 사용 권한과 거의 동일한 제한된 권한 집합을 받습니다. 기본적으로 "Longhorn"이 제공하는 것보다 추가 권한이 필요한 애플리케이션은 해당 애플리케이션 매니페스트에서 해당 추가 권한을 요청해야 합니다.

사용자가 이러한 애플리케이션을 처음 실행할 때 "Longhorn" 신뢰 관리자는 상승된 권한 요청을 평가하고, 사용자에게 애플리케이션의 권한 요청 부여와 관련된 제안된 위험 수준을 알리고, 해당 위험 수준에 대한 제안된 응답을 제공합니다. 사용자가 트러스트 관리자가 애플리케이션에 요청된 권한을 부여하도록 허용하면 트러스트 관리자는 이 정보를 기록합니다. 설치된 애플리케이션의 후속 실행은 보안 경고 없이 진행됩니다.

현재 로컬로 애플리케이션을 설치하면 LocalComputer 영역에서 로드되기 때문에 FullTrust 권한 집합이 수신됩니다. CAS(코드 액세스 보안)는 "Longhorn" 애플리케이션에서 다르게 작동합니다. 로컬(또는 설치된) 애플리케이션은 로컬에 설치되어 있기 때문에 FullTrust를 자동으로 받는 대신 사용자가 다운로드한 사이트의 보안 정책에 따라 실행됩니다.

애플리케이션, 해당 구성 요소 및 리소스를 로드할 때 "Longhorn"은 다음과 같은 CLR(공용 언어 런타임) 보안 시스템에 증거를 제공합니다.

  • 인터넷 영역 및 원본 사이트(Uniform Resource Identifier [URI]에서)
  • 게시자 및 모듈 이름(배포 매니페스트에서)

CAS는 애플리케이션의 증거에 따라 액세스 권한에 대한 보안 정책 기반 적용을 제공합니다.

애플리케이션의 배포 매니페스트는 새 버전의 애플리케이션을 확인할 때 "Longhorn"에서 사용해야 하는 업데이트 간격을 지정할 수 있습니다. "Longhorn"이 새 버전을 사용할 수 있음을 감지하면 백그라운드에서 새 버전을 다운로드하고 설치합니다. 다음에 사용자가 애플리케이션을 실행할 때 새 버전을 받습니다.

애플리케이션을 설치할 때 "Longhorn"은 이전 버전(있는 경우)을 유지합니다. 필요한 경우 이전 버전으로 쉽게 롤백하거나 프로그램 추가/제거를 사용하여 애플리케이션을 완전히 제거할 수 있습니다. IT 부서는 핸즈프리 배포를 위해 애플리케이션 설치를 클라이언트 시스템에 푸시할 수 있습니다.

프로젝트를 컴파일할 때 애플리케이션을 배포하는 방법을 지정하고, 일반적으로 소스 코드를 거의 또는 전혀 변경하지 않고 다시 컴파일하여 배포 시나리오를 변경할 수 있습니다.

개발자 프로그램은 처음에 MSAvalon.Windows.Application 클래스의 인스턴스를 통해 많은 "Longhorn" 애플리케이션 지원과 상호 작용하므로 해당 클래스를 살펴보겠습니다.

애플리케이션 클래스

"Longhorn" 프로그램에는 항상 애플리케이션 개체의 단일 인스턴스가 포함됩니다. 이 개체는 MSAvalon.Windows.Application 클래스에서 직접 또는 간접적으로 파생되며 다음 함수를 수행합니다.

  • 애플리케이션의 진입점, 캡슐화 및 범위를 제공합니다.
  • 애플리케이션이 애플리케이션을 구성하는 페이지에서 코드 및 상태를 공유할 수 있도록 허용
  • 애플리케이션 수준 이벤트 제공
  • 애플리케이션 창의 컬렉션을 유지 관리합니다.
  • 보안 모델 제공
  • 애플리케이션에서 사용하는 모든 리소스를 정의합니다.

MSAvalon.Windows.Application 클래스는 애플리케이션에 대한 기본 애플리케이션 지원을 제공합니다. 일반적으로 애플리케이션에 낮은 오버헤드가 필요하고 페이지 탐색 기능을 사용하지 않는 경우에 사용합니다. 그러나 대부분의 "Longhorn" 플랫폼 애플리케이션은 MSAvalon.Windows.Application 상속하고 탐색 지원을 추가하는 MSAvalon.Windows.NavigationApplication 클래스와 밀접하게 관련된 사용합니다. 다음 섹션에서는 NavigationApplication 클래스에 대해 자세히 설명합니다. 일반적으로 적절한 기본 클래스를 상속하고, 필요에 따라 기본 클래스 메서드를 재정의한 다음, 사용자 지정 시작 또는 종료 프로시저를 제공하기 위해 이벤트를 등록하는 클래스를 정의합니다.

여기에 표시된 SimpleApplication1.cs 원본 파일 목록은 Application 개체를 사용하는 방법을 보여 줍니다. EntryClass.Main 메서드는 MyApp특수화된 애플리케이션 개체를 만들고 Run 메서드를 호출하여 애플리케이션을 시작합니다. MyApp 클래스는 애플리케이션이 시작될 때 제어를 수신하는 OnStartingUp 메서드를 재정의합니다. 시스템에서 OnStartingUp 메서드를 호출할 때 애플리케이션의 주 창을 만들고 창에 텍스트를 추가하고 창을 표시하는 도우미 메서드를 호출합니다.

SimpleApplication1.cs

using System;
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Media;

namespace IntroLonghorn {
  public class MyApp : MSAvalon.Windows.Application {
    MSAvalon.Windows.Controls.SimpleText txtElement;
    MSAvalon.Windows.Window              mainWindow;

    protected override void OnStartingUp (StartingUpCancelEventArgs e) {
      base.OnStartingUp (e);
      CreateAndShowMainWindow ();
    }

    private void CreateAndShowMainWindow () {
      // Create the application's main window
      mainWindow = new MSAvalon.Windows.Window ();

      // Add a dark red, 14 point, "Hello World!" text element
      txtElement = new MSAvalon.Windows.Controls.SimpleText ();
      txtElement.Text = "Hello World!";
      txtElement.Foreground = new
       MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed);
      txtElement.FontSize = new FontSize (14, 
                                          FontSizeType.Point);
      mainWindow.Children.Add (txtElement);
      mainWindow.Show ();
    }
  }

  internal sealed class EntryClass {
    [System.STAThread]
    private static void Main () {
      MyApp app = new MyApp ();

      app.Run ();
    }
  }
}

다음 명령줄을 사용하여 SimpleApplication1.cs 소스 코드를 실행 가능한 애플리케이션으로 컴파일했습니다. 참조된 어셈블리에 대한 경로를 조정해야 할 수도 있습니다.

csc /r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\PresentationCore.dll
    /r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\PresentationFramework.dll
    /r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\WindowsBase.dll
    SimpleApplication1.cs

Application 클래스에는 다양한 유용한 속성, 메서드 및 이벤트가 포함되어 있습니다. 예를 들어 애플리케이션 클래스는 OnShuttingDown 가상 메서드를 재정의하여 사용자 지정 종료 동작을 제공할 수 있습니다. 또한 애플리케이션 클래스는 다른 클래스가 시작 및 종료 알림에 등록할 수 있도록 StartingUpShuttingDown 이벤트를 제공합니다. Shutdown 메서드를 사용하면 프로그래밍 방식으로 애플리케이션의 종료를 시작할 수 있습니다.

소스 코드의 여러 위치에서 애플리케이션 개체를 참조할 수 있습니다. 따라서 Application 클래스는 애플리케이션 개체에 대한 참조를 반환하는 Current 정적 속성을 제공합니다. 다음 코드 조각에서는 Current 속성을 사용하여 애플리케이션 개체를 찾고 종료 이벤트 알림에 등록합니다.

MyApp app = (MyApp) MSAvalon.Windows.Application.Current;
  app.ShuttingDown += new
       Application.ShuttingDownEventHandler (ShutDownHandler);
§
private static void
 ShutDownHandler (object sender, MSAvalon.Windows.ShuttingDownEventArgs e) {
§
}

NavigationApplication 클래스

애플리케이션에 대한 탐색 지원을 원하는 경우 일반적으로 MSAvalon.Windows.Application 클래스를 확장하는 MSAvalon.Windows.Navigation.NavigationApplication 클래스를 사용합니다. NavigationApplication 클래스를 사용하지 않고 탐색 기반 애플리케이션을 빌드할 수 있지만 클래스를 사용하면 애플리케이션에 다음과 같은 추가 기능이 제공됩니다.

  • 탐색 기반 애플리케이션 작성을 간소화합니다. 일반적으로 클래스를 서브클래스할 필요가 없습니다.
  • 연결을 사용할 수 있는 시기를 결정합니다.
  • 탐색, NavigationProcess, 탐색된, NavigationError, LoadCompleted중지된같은 탐색 이벤트를 제공합니다. 이 이벤트는 애플리케이션의 창에서 적절한 이벤트가 발생할 때 발생합니다.
  • 페이지 간 상태 공유
  • 여러 페이지에서 공유되는 속성 값에 대한 컨테이너를 제공합니다.
  • 기본적으로 초기 창을 여는 정책을 구현합니다.

외부에서 탐색 애플리케이션의 사용자는 애플리케이션의 잘 정의된 진입점으로만 이동할 수 있습니다. 그러나 내부적으로 개발자는 이벤트를 연결하여 탐색을 제어합니다. 창 또는 프레임이 새 페이지로 이동하려고 시도하는 시기와 탐색이 완료된 시기를 확인할 수 있습니다. 모든 탐색을 취소하거나 리디렉션할 수 있습니다. 대상 페이지의 ID를 확인할 수 있습니다. 탐색 오류를 처리할 수 있습니다.

친숙한 탐색 모델을 사용하면 애플리케이션을 쉽게 사용할 수 있습니다. 탐색 애플리케이션은 웹과 유사한 동작을 제공합니다. 애플리케이션은 하이퍼링크를 사용하고, 앞으로 및 뒤로 단추를 제공하고, 즐겨찾기 목록을 표시하고, 페이지 기록을 유지할 수 있습니다. "Longhorn" NavigationApplication 클래스 및 관련 클래스는 이러한 기능에 대한 모든 지원을 제공합니다.

탐색 애플리케이션은 온라인 또는 오프라인에서 작동하며 브라우저에서 애플리케이션을 호스트하든 애플리케이션을 독립 실행형으로 실행하든 동일하게 작동합니다. 또한 이 웹 유사 동작을 완벽하게 제어할 수 있습니다. 필요에 따라 사용자 환경을 사용자 지정할 수 있습니다. Travelog 항목을 삽입, 제거 및 수정하여 전달 및 뒤로 작업이 이동하는 위치를 제어할 수 있습니다. 기록에 기록되는 페이지(진입점)를 정의할 수 있습니다.

탐색 애플리케이션은 일반적으로 MSAvalon.Windows.Navigation.NavigationWindow 클래스의 하나 이상의 인스턴스를 만듭니다. 여기에 표시된 SimpleApplication2.cs 목록은 이러한 클래스의 사용을 보여 줍니다. 이 목록은 NavigationApplicationNavigationWindow 클래스를 사용한다는 점을 제외하고 SimpleApplication1.cs 동일합니다.

SimpleApplication2.cs

using System;
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Media;
using MSAvalon.Windows.Navigation;

namespace IntroLonghorn {
  public class MyApp : MSAvalon.Windows.Navigation.NavigationApplication {

    protected override void OnStartingUp (StartingUpCancelEventArgs e) {
      base.OnStartingUp (e);
      CreateAndShowMainWindow ();
    }

    private void CreateAndShowMainWindow () {

      // Create the application's main window
      mainWindow = new MSAvalon.Windows.Navigation.NavigationWindow ();

      // Fill window with appropriate controls
      §
      // Show the window
      mainWindow.Show ();
    }
  }

  internal sealed class EntryClass {
    [System.STAThread]
    private static void Main () {
      MyApp app = new MyApp ();
      app.Run ();
    }
  }
}

지금까지 본 코드는 기존 프로그래밍 모델의 또 다른 변형일 뿐입니다. 유일한 새로운 측면은 내가 사용한 실제 클래스입니다. 그러나 대부분의 경우 이 코드를 실제로 많이 작성하지는 않습니다. 조금만 우회하여 이 동일한 코드를 훨씬 더 간결하고 최소한 더 이해하기 쉬운 방식으로 작성할 수 있는 새로운 프로그래밍 언어에 대해 알아보겠습니다.

XAML(Extensible Application Markup Language)

많은 애플리케이션에서 작성하는 코드의 대부분은 애플리케이션의 UI를 만들고 업데이트하는 것과 관련이 있습니다. 실제로 이전 예제에서는 UI를 만드는 데 필요한 코드 이외의 코드가 없었습니다. 지난 몇 년 동안 많은 개발자가 사용 가능한 여러 태그 언어 중 하나를 사용하여 애플리케이션의 UI를 작성하고 정의하는 것을 선호하기도 했습니다. "Longhorn" 플랫폼은 XAML(Extensible Application Markup Language; "Zamel"으로 발음됨)이라는 새 태그 언어를 정의합니다.

태그 언어를 사용하여 UI를 정의하면 절차적 프로그래밍 언어를 사용하는 것에 비해 여러 가지 이점이 있습니다. 이러한 장점은 다음과 같습니다.

  • 더 명백한 컨트롤 계층 구조
  • 더 명백한 속성 상속
  • 도구별 태그 언어의 보다 쉬운 처리 및 해석
  • UI 및 절차 코드의 잠재적 분리

XAML을 좋아하며, 이 챕터에서 지금까지 보여 준 절차 형식 코딩을 사용하기보다는 UI를 정의하는 데 사용하는 것을 선호합니다. 그러나 XAML만 사용하여 필요한 모든 작업을 수행할 수 있다고 생각하지 마세요.

설명서에서 "문서는 XAML로 완전히 작성되어 브라우저에 표시되는 경우가 많습니다." 나는 이 문장이문서라는 단어를사용하고, 종종용어로 문을 한정한다는 점을 서둘러 지적한다. 정적 콘텐츠를 표시하는 문서를 작성할 때 순수 XAML로 만들 수 있습니다. 데이터 바인딩을 사용하여 XAML만 사용하여 데이터 원본의 콘텐츠를 표시하고 업데이트하는 문서를 작성할 수도 있습니다. XAML만 사용하여 애니메이션 및 마우스 오버 효과를 정의할 수 있습니다. XAML만 사용하여 많은 작업을 수행할 수 있습니다. (사실, XAML에서 가능한 한 많은 작업을 시도하고 코드에서 가능한 한 적게 하려고 합니다. 내 애플리케이션은 버그가 적고 작성 코드가 적을수록 더 빠르게 작동하는 것처럼 보입니다.) 그럼에도 불구하고 프로덕션 애플리케이션을 작성하려면 일반적으로 이벤트에 대응하거나, 사용자 지정 의사 결정 논리를 제공하거나, 다른 많은 비 UI 작업을 포함해야 하므로 XAML과 코드를 혼합해야 합니다. 다행히도, 이것은 매우 쉽게 할 수 있습니다.

3장에서 XAML 파일에 대해 더 자세히 설명하겠습니다. 이제 XAML에 대한 입문서에 대해 살펴보겠습니다.

  • XAML 요소 이름은 .NET Framework 클래스 이름입니다. XAML 요소를 정의할 때 XAML 요소와 이름이 같은 .NET Framework 클래스의 인스턴스를 효과적으로 만듭니다.
  • XAML 특성 이름은 일반적으로 클래스 인스턴스에서 이름이 같은 속성 또는 필드에 매핑됩니다.

SimpleApplication1.cs 프로그램에서는 창을 만들고 다음 코드를 사용하여 일부 컨트롤을 추가합니다.

// Create the application's main window
mainWindow = new MSAvalon.Windows.Window ();

// Add a dark red, 14 point, "Hello World!" text element
txtElement = new MSAvalon.Windows.Controls.SimpleText ();
txtElement.Text = "Hello World!";
txtElement.Foreground = new 
           MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed);
txtElement.FontSize = new FontSize (14, FontSizeType.Point);
mainWindow.Children.Add (txtElement);
mainWindow.Show ();

다음 XAML 문서에서는 정확히 동일한 UI를 생성합니다.

HelloWorld.xaml

<Window xmlns="https://schemas.microsoft.com/2003/xaml" Visible="true">
    <SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText>
</Window>

루트 Window 요소는 MSAvalon.Windows.Window클래스의 인스턴스를 만듭니다. 어떻게 든 빌드 시스템은 Window 명명된 XAML 요소가 msAvalon.Windows.Window클래스의 인스턴스를 참조한다는 것을 알아야 합니다. xmlns 특성 값은 이 매핑을 제공합니다.

XML 파서는 가장 최근의 범위 내 기본 네임스페이스 특성, xmlns지정된 네임스페이스를 기준으로 정규화되지 않은 요소 이름을 해석합니다. "https://schemas.microsoft.com/2003/xaml"의 xmlns 값을 지정하는 경우빌드 시스템은 정의 요소의 정규화되지 않은 요소 이름 또는 해당 하위 요소 중 하나를 미리 정의된 네임스페이스 집합의 클래스 이름으로 해석합니다.

C#을 예로 사용하여 좀 더 구체적인 용어로 다시 살펴보겠습니다. xmlns 선언은 코드에 문을 사용하여 여러 효과적으로 추가합니다. 그런 다음 빌드 시스템은 각 정규화되지 않은 XAML 요소 이름을 가능한 네임스페이스에 대한 컨텍스트를 제공하는 선언을 사용하여 클래스 이름으로 해석합니다. 목록이 변경될 수 있지만 이 작성 시 기본 네임스페이스 특성의 표준 값을 지정하면 문을 사용하여 다음 포함됩니다.

using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Controls.Primitives;
using MSAvalon.Windows.Data;
using MSAvalon.Windows.Documents;
using MSAvalon.Windows.Shapes;
using MSAvalon.Windows.Media;
using MSAvalon.Windows.Media.Animation;
using MSAvalon.Windows.Navigation;

또한 표준 기본 네임스페이스 선언은 빌드 시스템이 이전에 나열된 네임스페이스의 클래스를 포함하는 PresentationFrameworkPresentationCore 어셈블리를 참조하도록 합니다.

Window 요소의 Visible 특성을 true설정합니다. Show 메서드를 호출하여 창을 표시하는 원래 코드에 해당합니다.

Window 요소 정의 내에 SimpleText 요소를 중첩했습니다. 그러면 시스템에서 MSAvalon.Windows.Controls.SimpleText 개체 인스턴스화하고, Window 개체의 자식으로 만들고, 단순 텍스트 개체의 값을 "Hello World!" 문자열로 설정하도록 시스템에 지시합니다.

이전 XAML 코드를 HelloWorld.xaml이라는 파일에 저장하고 파일을 실행합니다. 브라우저는 그림 1-1과 같이 파일의 XAML 코드를 해석하고 UI를 표시합니다.

더 큰 이미지 보려면 여기를 클릭하십시오.

그림 1-1. XAML 버전의 Hello World를 표시하는 브라우저(더 큰 이미지를 보려면 그림 클릭)

이전에 나열된 기본 네임스페이스 중 하나에 정의되지 않은 .NET 클래스를 사용할 수 있습니다. 일반적인 예는 만드는 어셈블리의 클래스를 사용하는 것입니다. 빌드 시스템은 XAML 원본 파일에서 지정한 요소 이름을 올바른 어셈블리의 적절한 .NET 클래스에 매핑할 수 있어야 합니다. XAML은 ?라는 XML 처리 명령(PI)을 정의합니다. 매핑 이 연결을 만드는 데 사용합니다.

? 매핑 PI를 사용하면 CLR 네임스페이스 및 어셈블리에 매핑되는 XML 네임스페이스 접두사를 정의할 수 있습니다. 이 네임스페이스 접두사로 XAML 요소 이름을 한정하면 빌드 시스템에 요소 이름을 사용하고 이름에 CLR 접두사를 추가하고 결과 이름을 사용하여 클래스의 인스턴스를 만들도록 지시합니다. 컴파일러는 클래스의 정의를 찾을 수 있도록 지정된 어셈블리를 참조합니다.

다음 예제에서는 WiseOwl.Statistics.Library 어셈블리에 있는 정의인 WiseOwl.Statistics.PoissonDeviate 클래스의 인스턴스를 만듭니다.

<?Mapping XmlNamespace="stat" ClrNamespace="WiseOwl.Statistics"
                              Assembly="WiseOwl.Statistics.Library" ?>
<Window xmlns="https://schemas.microsoft.com/2003/xaml" Visible="true">
    <SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText>
    <stat:PoissonDeviate Mean="5.0" />
</Window>

XAML이 .NET Framework UI 클래스를 사용하는 코드를 생성하는 또 다른 방법이라는 점을 충분히 강조할 수는 없습니다. 실제로 비주얼 디자이너를 사용하여 XAML UI 사양을 그래픽으로 표시하는 도구가 있을 수 있습니다. 또 다른 도구는 반대로 UI를 디자인하고 XAML 파일로 저장할 수 있습니다. 그러나 또 다른 도구는 WinForms 디자이너의 작동 방식과 유사한 절차 코드로 UI 디자인을 저장할 수 있습니다. 이러한 모든 방법은 동일한 정보를 지정하는 다른 방법입니다.

이 장 앞부분에서 브라우저가 창에서 XAML 파일을 렌더링할 수 있다고 언급했습니다. 브라우저는 XAML 파일에 방금 표시된 간단한 예제와 같이 태그만 포함된 경우에만 이 작업을 수행할 수 있습니다. UI가 더 복잡해지면 일반적으로 UI를 설명하는 XAML 외에도 이벤트 처리기 및 기타 비마크업 소스 코드를 사용해야 합니다. 혼합 소스 코드 베이스(태그 및 태그가 아닌 소스 코드)가 있을 때마다 MSBuild 유틸리티를 사용하여 태그 및 소스 코드를 컴파일해야 합니다. 컴파일 후 애플리케이션을 독립 실행형 구성 요소로 실행하거나 브라우저에 결과 UI가 표시되도록 할 수 있습니다.

요약

좋습니다! 이제 새 애플리케이션 모델의 기본 사항을 이해하게 되었습니다. 매우 간단한 UI임에도 불구하고 태그를 사용하여 선언적으로 UI를 만드는 방법을 알아보았습니다. XAML 파일을 사용하여 해당 웹 페이지를 작성하고 사용자가 찾아볼 수 있도록 해당 파일을 서버에 배포할 수 있습니다. 그러나 더 흥미로운 시나리오는 일반적으로 애플리케이션을 배포하기 전에 컴파일해야 합니다. 이제 바로 이동하여 "Longhorn" 애플리케이션을 빌드하고 배포하는 방법을 알아보겠습니다.

2장을 계속합니다. "Longhorn" 애플리케이션빌드합니다.

© 2003 Microsoft Corporation. 모든 권한이 예약되어 있습니다.

IntelliSense, Microsoft, MSDN, MS-DOS, Visual Basic .NET 및 Visual Studio .NET은 미국 및/또는 기타 국가에서 Microsoft Corporation의 등록 상표 또는 상표입니다. 여기에 언급된 다른 제품 및 회사 이름은 해당 소유자의 상표일 수 있습니다.