항상 새로운 기술을 접할 때에는 그 기술에 대한 전반적인 아키텍처와 구성, 특히 Overview를 읽어보는 것이 많은 도움이 되는 것 같아요. 저도 오랫만에 WPF스타일을 접해서 많은 혼란을 겪고 있어서 생각도 정리할 겸 MSDN 토픽 하나를 날림 번역해봤어요.

원본 글 : http://msdn2.microsoft.com/en-us/library/cc221365(vs.95).aspx

실버라이트는 애플리케이션 개발자에게 브라우저에서 실행되는 웹 애플리케이션을 개발하고 배포할 수 있게 하는 기술입니다. 이 토픽은 실버라이트 애플리케이션의 개발, 실버라이트 애플리케이션 및 라이브러리 어셈블리의 구현, 리소스 파일의 조직, 애플리케이션 서비스의 사용, 그리고 실버라이트가 제공하는 유연한 패키징 옵션을 다양한 개발 시나리오에 공급하는 것에 대한 개요를 제공합니다. 이 토픽은 클라이언트 측 캐싱에 관한 간단한 논의로 마무리합니다.

이 토픽은 다음과 같은 섹션을 포함합니다.

  • 애플리케이션 클래스, 어셈블리 및 패키지
  • 라이브러리 어셈블리
  • 리소스 파일
  • 패키지에 포함 vs 필요할 때 요청
  • 애플리케이션 서비스
  • 실버라이트 애플리케이션
  • 관련 토픽

실버라이트 애플리케이션에 관련된 정보는 Deployment (Silverlight 2)를 보세요.


애플리케이션 클래스, 어셈블리 및 패키지

각 실버라이트 애플리케이션은 반드시 실버라이트 플러그인 컨트롤에 의해 다운로드 된 이후 구동start up시키기 위한 최소한의 기능이라도 구현해야만 합니다. 만약 각 실버라이트 애플리케이션이 구동 기능을 각자의 방법으로 구현했다면 실버라이트 플러그인 컨트롤이 가능한 모든 구현을 공급하는 것은 불가능할 것입니다. 실버라이트 플러그인 컨트롤은 각 실버라이트 애플리케이션이 엔트리 포인트entry point라고 하는 잘 알려진 방법을 명시적으로 구동 기능을 구현하기를 기대합니다. 실버라이트 애플리케이션에서 엔트리 포인트는 다음의 항목들의 조합이 됩니다.

  • 애플리케이션 클래스application class라고 하는 Application에서 파생된 클래스.
  • 애플리케이션 어셈블리application assembly라고 하는 이 클래스를 구현하는 어셈블리.
  • 애플리케이션 클래스와 엔트리 포인트를 이루는 애플리케이션 어셈블리를 식별하는 메타 데이터.

최소한의 실행 가능한 실버라이트 애플리케이션은 애플리케이션 어셈블리(애플리케이션 클래스를 가지는)와 엔트리 포인트 메타데이터 모두를 포함하는 .xap 파일 확장자로 압축된 ZIP 파일입니다. .xap 파일은 애플리케이션 패키지로 알려져 있고 실버라이트 플러그인 컨트롤이 다운로드하고 실행하는 파일입니다.

애플리케이션 클래스와 애플리케이션 어셈블리를 어떻게 구현하고 패키지에 대한 자세한 정보는 Developing a Silverlight Application Assembly를 보세요.


라이브러리 어셈블리

애플리케이션 어셈블리가 일반적으로 실버라이트 애플리케이션의 메인 UI와 기능을 이루고 통합하는 반면, 라이브러리 어셈블리library assembly는 추가적인 애플리케이션 UI와 기능을 캡슐화할 수 있습니다. 라이브러리 어셈블리들은 애플리케이션을 더 쪼개진 요소로 분해하여 복잡도를 낮추고 다수의 애플리케이션에 걸쳐 UI와 기능을 공유하는 등의 다양한 이유로 사용됩니다.

실버라이트 라이브러리 어셈블리에 대한 자세한 정보는 Developing a Silverlight Library Assembly를 보세요.


리소스 파일

애플리케이션과 라이브러리 어셈블리가 실버라이트 애플리케이션의 실행가능한 형태를 캡슐화하는 한편, 실버라이트 애플리케이션은 오디오, 비디오, 이미지, XML 및 XAML 파일과 같은 비실행 데이터를 포함할 수도 있습니다. 이런 유형의 파일들은 집합적인 리소스 파일로 알려져 있고 다양한 방법으로 패키징될 수 있습니다.

리소스 파일의 작동에 대한 자세한 정보는 Application Services를 보세요.


패키지에 포함 vs 필요할 때 요청

실버라이트 애플리케이션은 하나의 애플리케이션 어셈블리, 0개 혹은 한개 이상의 라이브러리 어셈블리 및 0개 혹은 한개 이상의 리소스 파일의 덩어리입니다. 이 다양한 파일들이 어떻게 패키지되느냐는 가장 짧은 시간 동안 유저에게 올바른 기능을 제공하는 것의 평가에 달려있습니다.

앞서 얘기한 것처럼, 실버라이트 애플리케이션은 반드시 애플리케이션 클래스를 구현하는 애플리케이션 어셈블리를 가진 애플리케이션 패키지를 포함해야 합니다. 추가적으로 애플리케이션 패키지는 라이브러리 어셈블리와 리소스 파일을 포함할 수 있습니다. 애플리케이션 패키지는 실버라이트 애플리케이션을 시작하기 위해 실버라이트 플러그인 컨트롤이 다운로드하기 때문에 애플리케이션 패키지는 가급적 빠르게 다운로드 될 수 있도록 가능한 작아야 합니다. 따라서 애플리케이션의 UI와 기능을 구성하여 그것 없이는 애플리케이션의 실행이 불가능한 파일들만이 포함되어야 합니다. 예를 들어, 스프레드시트 애플리케이션과 같이 데이터를 입력하고 보여주는 기능만을 요구하는 애플리케이션을 생각해 봅시다. 애플리케이션 패키지에 포함되어 있는, 애플리케이션 어셈블리와 라이브러리 어셈블리와 리소스 파일을 포함하는 파일들이 바로 패키지에 포함된in-package 파일을 말합니다.

스프레드시트 애플리케이션은 또한 바 차트나 파이 차트처럼 언제나 사용되지는 않는 다른 데이터 뷰를 제공할 것입니다. 실버라이트 애플리케이션의 관점에 의하면, 애플리케이션의 선택적인 UI와 기능을 구성하는 파일들은 필요할 때 다운로드 될 수 있고 이것이 필요할 때 요청on-demand되는 파일입니다.

올바르게 구성된 스프레드는 사용자들이 애플리케이션 UI와 기능에 필요한 최소한의 초기 다운로드 비용이 들도록 하고 그들이 선택적인 기능을 원할 때만 추가적인 다운로드 비용이 들도록 합니다.

패키지에 포함하거나 필요할 때 요청되는 라이브러리 어셈블리를 어떻게 배포하는지에 대한 자세한 정보는 Developing a Silverlight Library Assembly를 보세요. 리소스 파일의 경우는 Application Services를 보세요.


애플리케이션 서비스

Application은 또한 일반적으로 애플리케이션에서 요구하는 몇 가지 애플리케이션 서비스를 제공합니다. 가장 중요한 서비스는 애플리케이션이 시작될 때 보여줄 사용자 인터페이스(UI)를 지정하는 기능입니다. 추가적인 서비스는 라이프타임 관리, 애플리케이션 스코프 리소스와 속성, 초기화 파라미터에 접근하기 및 처리되지 않은 예외 검출과 응답입니다.

Application 클래스에 의해 제공되는 서비스에 대한 자세한 정보는 Application Services를 보세요.


실버라이트 애플리케이션

지금까지 애플리케이션 클래스, 애플리케이션 어셈블리, 애플리케이션 패키지, 애플리케이션 서비스, 라이브러리 어셈블리 및 리소스 파일의 개요를 살펴봤습니다. 또한 실버라이트가 유연한 패키징과 배포를 위해 어떻게 in-package와 on-demand 파일을 지원하는지도 살펴봤습니다. 각 실버라이트 애플리케이션은 다음과 같은 방법으로 표현되는 하나 혹은 모든 것들의 조합입니다.

  • [필수] - 애플리케이션 어셈블리로 구현되고 애플리케이션 패키지에 포함된 애플리케이션 클래스와 서비스.
  • [선택] - 필수적인 애플리케이션 UI와 기능을 캡슐화하고 애플리케이션 패키지에 포함되는 in-package 라이브러리 어셈블리와 리소스 파일.
  • [선택] - 선택적인 UI와 기능을 캡슐화하고 애플리케이션 패키지와 나란히 포함되는 on-demand 라이브러리 어셈블리와 리소스 파일.

실버라이트 애플리케이션의 가능한 조합은 다음 그림에서 설명하고 있습니다.


관련 토픽

컨셉
Developing a Silverlight Application Assembly
Developing a Silverlight Library Assembly
Resource Files
Application Services
Deployment (Silverlight 2)

참조
Application 클래스

신고
Posted by gongdo
오 Main이여 어디있는가?

애플리케이션이 실행 될 때
많은 프레임웍이 그렇듯 WPF도 애플리케이션을 대표하고 애플리케이션 전역에서 공통적으로 필요한 많은 기능들을 제공하는 클래스를 제공합니다. VC프로그래머라면 MFC에서 애플리케이션이 CWinApp를 상속받은 클래스를 theApp라는 전역 개체로 인스턴스화 하여 사용했던 기억이 날 거에요.

WPF는 그러한 애플리케이션의 대표자로써 Application 클래스를 제공합니다. Application 클래스는 .NET Framework 3.0에서 System.Windows 네임스페이스에 정의되어 있고 마크업(XAML)에서는 Application 엘리먼트로 표현되지요.
예를 들어 XAML에서 Window1.xaml을 시작 윈도로 정의하는 애플리케이션을 다음과 같이 정의할 수 있습니다. (XAML에 대한 내용은 이 글의 주제에서 벗어나니 다른 문서를 참고해주세요.) 어떻게 만드냐구요? 간단해요 이 포스팅을 확인하시고 먼저 .NET Framework 3.0 개발환경을 갖추신 후 VS2005에서 새 프로젝트->C#->.NET Framework 3.0->Windows Application(WPF)를 선택하세요.

APP.XAML

<Application

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    x:Class="App" StartupUri="Window1.xaml" />

WINDOW1.XAML

<Window

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    x:Class="Window1" Width="300" Height="300" />


컴파일하고 빌드해보면 오 놀라워라 애플리케이션이 실행되네요!

윈도우즈 개발자라면 여기서 놀라야 해요. 왜냐? 무슨 언어를 사용하든 윈도우즈 환경에서 윈도우즈 애플리케이션(여기에서는 exe형태로 실행가능한 독립 실행형 애플리케이션)은 Entry point라고 불리는 메인 프로시저(WinMain)를 OS가 호출함으로써 시작되기 때문이죠. C, C++은 말할것도 없고 C#, 심지어 그 오래된 VB조차도 엔트리 포인트를 제공하는데, XAML은 생긴건 HTML이랑 별 차이도 없어보이는게 브라우저 상에서 표시되는 것도 아니고 곧바로 윈도를 띄울 수 있는 exe파일을 만들었잖아요?

놀란 가슴을 진정시키고 생각해보죠. WPF가 제 아무리 편리하고 화려한 기술로 무장하고 있어봤자 윈도우즈 애플리케이션입니다. 지가 무슨 재주로 엔트리 포인트도 없이 애플리케이션으로 실행될 수 있겠어요?
분명 자기가 여러분보다 스마트한줄 알고 있는 VS2005(혹은 Orcas)가 컴파일 과정에서 코드를 자동으로 생성 했음을 짐작할 수 있을거에요. 그런데 사실 VS2005가 저보다는 훨씬 스마트한 것 같아요. VS가 발전하다보면 제가 필요 없어질 날이 올지도 몰라요ㅠ.ㅜ

애플리케이션의 Main 찾기
그러면, 자동으로 생성된 파일은 어딨을까요?
여기에서 이 포스팅의 주제가 나옵니다. 오 Main이여 어디있는가?

아주 조금 눈치 빠른 개발자라면 회심의 미소를 지으며, 어쩌면 머리를 쓸어 넘기며 이렇게 얘기할 것입니다.
"훗, 범인은 솔루션 익스플로러 안에 있어. 범인은 app.xaml 바로 아래에 들어가 있는 app.xaml.cs 너다! 게다가 app.xaml.cs를 보면 Application을 상속하는 App 클래스가 정의되어 있어. 움직일 수 없는 증거지. 음하하핫!"

안됐지만 땡입니다.
app.xaml.cs도 물론 새 WPF 프로젝트를 만들때 위저드가 자동으로 만들어준 파일이긴 한데, app.xaml.cs를 삭제해도 아무런 이상 없이 잘 돌아갑니다. 정말이에요. 한번 새 WPF Windows 애플리케이션을 하나 만들고 app.xaml.cs 파일을 지워보세요. Window1.xaml.cs도 마찬가지구요.

그렇다면 진짜 범인은,
범인은.
범인은!
범인은?

해당 프로젝트 폴더아래의 obj\Debug (또는 Release)안에 App.g.cs안에 있어요. 끝.

썰렁.
옙. 썰렁하지만 그냥 이게 다에요.
...라고 하면 돌이 날라올지도 모르니 좀 더 자세히 얘기해볼께요.

XAML이 컴파일 될 때
서두에 WPF 애플리케이션은 Application 클래스로 대표되고 Application은 XAML에서 Application 엘리먼트로 표현된다고 했습니다. 이 말은 반대로 생각하면 XAML에서 Application 엘리먼트는 내부적으로 Application 클래스를 생성한다고도 할 수 있어요. 따라서 XAML에서 사용된 Application 엘리먼트는 우리의 스마트한 VS2005의 컴파일러가 내부적으로 Application 클래스를 정의하는 C#(또는 VB.NET) 코드를 생성할 거에요.

이렇게 컴파일러에 의해 자동으로 생성된 코드가 바로 "파일명.g.cs"(VB일 경우 .vb)인데요 추가 확장자 .g는 바로 자동으로 생성되었다는 Generated를 의미합니다.

기술적으로 좀더 정확하게 표현하자면 Application 엘리먼트는 반드시 x:Class 어트리뷰트를 통해 생성할 클래스의 이름을 정의해야하고 이렇게 정의된 클래스가 Application 클래스를 상속하여 코드로 구현되는거지요. 위의 예제에서라면 x:Class="App"라고 선언했으니 내부적으로 Class App : Application (VB.NET이라면 Class App Inherits Application)이란 코드를 생성해야겠죠. 이런 특성은 디자인타임에 프로젝트에 포함되어 컴파일되는 모든 XAML에 동일하게 적용되구요, 예를 들어 Window1.xaml이 어떤 클래스 정의을 가지고 있다면 Window1.g.cs란 파일이 생성되겠지요.

친절한 컴파일러씨
정말로 컴파일러가 필요한 클래스들을 정의했는지 app.g.cs를 열어볼까요? 눈치채셨겠지만 이미 다 확인하고 얘기하는거에요. 믿으세요. :-)

app.g.cs

//------------------------------------------------------------------------------

// <auto-generated>

//    This code was generated by a tool.

//    Runtime Version:2.0.50727.1302

//

//    Changes to this file may cause incorrect behavior and will be lost if

//    the code is regenerated.

// </auto-generated>

//------------------------------------------------------------------------------


using System;

// 나머지 using 선언은 생략...


namespace WindowsApplication2 {



    /// <summary>

    /// App

    /// </summary>

    public partial class App : System.Windows.Application {


        /// <summary>

        /// InitializeComponent

        /// </summary>

        [System.Diagnostics.DebuggerNonUserCodeAttribute()]

        public void InitializeComponent() {


            #line 4 "..\..\App.xaml"

            this.StartupUri = new System.Uri("Window1.xaml", System.UriKind.Relative);


            #line default

            #line hidden

        }


        /// <summary>

        /// Application Entry Point.

        /// </summary>

        [System.STAThreadAttribute()]

        [System.Diagnostics.DebuggerNonUserCodeAttribute()]

        public static void Main() {

            WindowsApplication2.App app = new WindowsApplication2.App();

            app.InitializeComponent();

            app.Run();

        }

    }


첫머리에 <auto-generated>라고 박혀있고 고쳐봤자 헛수고이니 삽질하지 말라고 친절하게 경고충고해주고 있네요.

다음으로 애플리케이션에서 사용하게될 어셈블리들을 using 문으로 선언해줬구요.
그 아래에 드디어 얘기 드린 Application을 상속하는 App 클래스의 정의가 나옵니다.
멤버 메소드로 InitializeComponent가 만들어져 있는데 자세한건 좀 이따가 보고 그 아래에 더 중요한 Main() 프로시저를 먼저 살펴볼께요.

네, 이 포스팅의 주제인 Main의 행방을 드디어 찾았네요. 이 시점에 바로 무릎을 치거나 이마를 치거나 손가락으로 딱 소리를 내면서 '그럼 그렇지 Main이 어디 가겠어!'라고 해야 합니다. 전 그랬어요. ㄱ-

Main의 코드 구성에 대해 설명드리는건 아마도 C#(또는 VB)를 해보신 분께는 무의미하겠구요, 그렇지 않은 분께는 죄송하게도 저 역시 .NET 언어를 제대로 공부하지 않은 상태라서 무리일 것 같습니다. 단순히 통빱으로 얘기드릴테니 헛소리한다 싶으면 가차없이 지적해주세요.

다시 반복하자면 Main() 프로시저는 곧 이 애플리케이션을 실행할 때 OS에 의해 호출되는 첫번째 프로시저이자 애플리케이션의 시작 지점이 됩니다. 흔히 엔트리 포인트라고 부르지요.
당연히 이 Main() 프로시저는 애플리케이션 전역에서 유일해야 하므로 Static 으로 선언되었죠.

바로 이 유일한 Main() 프로시저 내에서 우리가 작성할 애플리케이션의 새 인스턴스를 생성하고 뭐하는 놈인지 InitializeComponent 메소드를 호출한 후 너무나도 명백하게 애플리케이션을 시작하라는 Run 메소드를 호출하는게 전부입니다.

여기서 통밥이 있는 개발자라면 '아 Run은 애플리케이션이 어떻게든 종료되기 전까지는 반환되지 않겠군'이라고 감이 오실겁니다. 이에 대한 자세한 내용은 다음 기회로 미루고요. 먼저 밀려있는 InitializeComponent를 살펴보죠.

뭐 의미상으로는 명백합니다. 바로 해당 XAML에서 사용될 컴포넌트, 즉 마크업에서 정의된 엘리먼트나 엘리먼트의 어트리뷰트를 코드-비하인드의 클래스 및 속성으로 치환해주는 역할이죠.

곧바로 보기도 애매한 #line 지시자가 나오는데요, 보면 #line 4, #line default, #line hidden이 있네요. #line 4는 해당 라인의 해당 파일에 있는 코드라는 것을 의미하고, #line default/hidden은 디버깅시 브레이크 포인트를 보일지 숨길지 여부인데 어차피 이 코드들은 컴파일러가 자동으로 작성하니까 크게 중요하진 않아요.

중요한건, 아래의 코드죠.
this.StartupUri = new System.Uri("Window1.xaml", System.UriKind.Relative);
이건 좀 의미심장하죠? 바로 위의 #line 지시자가 가리키는 App.xaml의 4번째 라인을 볼까요?
StartupUri="Window1.xaml"
네, 바로 XAML에서 정의한 StartupUri가 어떻게 코드로 변환되었는지를 보여줍니다. XAML이 얼마나 직관적으로 프로그래밍을 할 수 있는지를 잘 보여줍니다.

나는 내 코드를 통제하고 싶다.
오 과연 친절한데다가 똑똑하기까지한 VS. 그간의 골치아픈 코드와의 전쟁은 가고 바야흐로 인간 중심적인 프로그래밍의 신천지가 열리는 것인가!

다시 한번 안됐지만 그럴리가 있겠습니까. 공짜 점심도 한두번이죠.
위의 예제야 단순한 코드라서 XAML의 장점이 눈에 띄지만 XAML이 만능은 아니에요.
분명히 XAML은 어떤 개체를 선언하고 속성을 설정하는데에는 C#, VB코드에 비해 보다 직관적이고 간단하지만 어떤 고도의 연산 작업이나 논리적인 상태를 관리하는데에는 절대적으로 코드가 우수합니다.

필연적으로 XAML의 선언만으로 코드를 자동 생성해서 쓰는게 아니라 내가 직접 작성한 코드를 끼워넣고 나아가 코드를 통해 XAML로 선언한 개체들을 제어할 필요가 있을 거에요. 개발자라면 내가 작성하는 애플리케이션의 코드는 내가 원하는대로 통제하고 싶어하는 게 당연하잖아요?

그런데 예제의 경우만 봐도 XAML에서 정의한 App 클래스가 멋대로 자동 생성 코드에서 정의 되어버렸죠. 그럼 자동으로 생성된 App 클래스를 수정해봤자 다시 컴파일하면 도루묵이 된단 얘기잖아요?!

상황이 역전되었지만 그럴리가 있겠습니까.
XAML에서 생성한 클래스는 얼마든지 개발자가 직접 작성한 코드에서 다시 정의할 수 있습니다. 바로 partial 키워드 덕분이죠.

쪼개고 쪼개고 또 쪼개고
객체지향의 개념이 등장한 이래로 코드 블럭은 점점 더 작아지고 갈라지고 전문화 되는게 일반적인 스타일이 되었죠. partial 키워드는 여기에 한술 더 떠서 동일한 클래스, 상속받거나 포함하는게 아닌 정확히 같은 클래스에 대한 정의를 코드의 다른 장소에서 할 수 있게 해줍니다.

※ 전통적인 C/C++에서 어떤 클래스를 컴파일러에게 알려주는 것을 선언(declaration)이라고 하고 선언된 클래스의 코드를 작성하여 구현한 것을 정의(definition)이라고 명백하게 구분하고 있지만 C#이나 VB처럼 선언과 동시에 정의하는 언어에서는 이 둘의 구분은 별 의미가 없을 것 같습니다. 본문에서 선언과 정의를 혼용하는 경우가 있으니 널리 양해 바랍니다.
다시 한번 졸린 눈을 비비고 App 클래스의 정의를 살펴볼까요?
public partial class App : System.Windows.Application
이 코드를 보고 아무 느낌이 없으셨다면 이미 이 글을 보실 필요가 없는 레벨의 분이거나 진지하게 자아비판을 좀 하셔야 할 분이겠습니다. 이 코드를 보고 뭔가 이상한 냄새를 맡았거나 partial이 뭐야? 하신 분은 축하합니다. 안드로메다 깐따삐야 별의 이름을 걸고 단언컨대 개발자로 대성하실거에요!

앞서 말한 것처럼 partial 키워드는 클래스의 정의를 다른 곳에서도 할 수 있게 하므로 App 클래스는 우리가 원하는 위치에 제어하고 싶은 코드를 자유롭게 배치할 수 있다는 거죠.

시작하면서 지워버렸던 App.xaml.cs 기억나시나요? 바로 여기에 위의 코드와 마찬가지로 Application을 상속하는 App 클래스가 정의되어 있었죠. 벌써 지워버린걸 어떻게 확인하겠습니까. 귀찮더라도 프로젝트를 하나 더 만들어서 확인해보죠.

App.xaml.cs

using System;

// 나머지 using 선언은 또 생략...

namespace WindowsApplication2

{

    /// <summary>

    /// Interaction logic for App.xaml

    /// </summary>


    public partial class App : System.Windows.Application

    {


    }

}


비록 내부에 아무런 코드도 없지만 컴파일러가 자동으로 생성한 App 클래스의 정의와 정확히 일치하는걸 확인할 수 있네요. partial 키워드가 서로 다른 위치에서 클래스의 정의를 할 수 있다고 해도 당연히 같은 클래스는 같은 형(type)을 가져야 합니다.

제가 얘기한게 참말인지 거짓말인지 확인하려면 간단히 partial 키워드를 지워보거나 public을 private으로 바꿔보시면 빌드에 실패하는 것을 확인할 수 있을거에요.

물론 C#이나 VB.NET을 제대로 공부하셨다면 partial 쯤이야 대수롭지 않게 여기시겠지만 저처럼 곁눈질로 공부하신 분이라면 MSDN을 참고하세요. 다행히 한글로도 있네요. :)


WPF는 화장빨?
WPF라고 해도 Foundation, 기초화장에 지나지 않아요. 화장이란건 때론 변장에 가까울 정도로 진할때도 있잖아요? WPF는 특히나 더 예쁘고 진한 화장을 위한 기초라고 생각해요. 그 뒤에는 아직 WIN32 API가 자리잡고 있죠. 뭔가 속은 듯한 기분도 들고 그렇죠?

하지만 Foundation이 '기초'화장이란것에 주목하세요. 분명 그 위에 개발자와 디자이너가 꿈꾸는 화려하고 멋진 인터페이스를 올려나갈 수 있다는게 더 중요하죠.

어쩌면 WPF가 화장빨인지 모르겠지만, 사실 사용자들에겐 밤새워 최적화한 눈물어린 코드 보다는 적당히 화사한 화장빨이 훨씬 더 잘 먹히잖아요? 늘 하는 얘기지만 좋은게 좋은거죠. :)


다음회 예고!
아직 XAML이 컴파일될 때 일어나는 비밀스런 일 중에 아직 소개하지 못한 것이 있었으니... 기대하시라 개봉박두?
신고
Posted by gongdo


티스토리 툴바