- 위 내용은 Daum Communication 구경택님의 자료를 바탕으로 했으며 저작권은 http://no7do.tistory.com/ 의 블로거 김도영과 구경택님에게 있음-

출처 : http://tong.nate.com/career/15334132

특집기사 Microsoft WPF

Windows Vista and WinFX™
차세대 운영체제 이런 예기는 이미 충분히 들었을 줄로 안다.
Windows Vista에 대한 예기들을 하면서 깔끔한 UI, 강화된 보안기능등에 대한
예기를 하면서도 정작 엄청나게 바뀐 내부적인 변화에 대해서는 섵불리
예기 하기가 쉽지 않은것은 그 변화 폭과 내용이 너무 엄청나서 일 것이다.

누가 그랬던가 Windows 3.x에서 Windows 95가 나올때 이상의 변화이다 라고
물론 그때도 UI적인 측면이 충격적으로 바뀠지만 그 보다 더 중요한 변화라고 하면
Win16 API에서 Win32 API로의 환경적인 변화가 실상 더 큰 변화 였다.

이번의 Windows Vista의 변화 역시 Win32 API와 .NET Framework가
WinFX라는 환경으로의 충격적인 진화와 확장이 된 버전으로 그 내부적인 환경의
변화를 설명할 수 있다.
 

WinFX는 아래와 같이 세 부분으로 크게 구성되어 있다.
-WPF -Presentation Foundation
-WCF -Communication Foundation
-WWF -Workflow Foundation

UI의 혁명적 변화를 이끌어 낼 WPF와 SOA를 단일환경으로 통합시릴 수 있는 WCF
그리고 Workflow로 비지니스 프로세스를 구조화 할 수 있는 WWF와 같은 요소들은
바로 WinFX를 구성하고 있는 주요 구성 요소이다.

이 중에서도 설명해 드릴 내용은 WPF라고 하는 UI의 혁명이다.
제가 백마디 하는 것 보다 데모 동영상을 보고나서 계속 이어가겠다.

동영상 URL:http://www.microsoft.com/products/expression/en/demos.mspx

일단은 보기에는 멋있다. 멋있는 정도가 아니라 무슨 방송용 화면이나 광고같기도 하다.
심지어는 마이널리티 리포터의 한 장면이 떠오를라 하려고 까지 한다.
문제는 저런 화면을 실제로 구현할 수 있는가 하는 것이다.
KBS 개그맨 중에서 백수들의 애환을 다루고 있는 누구는
"안돼는게 어딧니~" 라는 대사로 항상 코너를 마무리 지었다.
말 그대로 안되는 건 사실상 거의 없다. 하지만 그 정도의 혁신적인 UI와 환경을
구축하는데 얼마 만큼의 시간과 비용이 소비되는가 하는게 문제 일 것이다.

WPF는 이런 완성된 그리고 엄청난 UI를 비교적 쉽게 구현할 수 있는 환경을 예기하고
있다. WPF는 아래와 같은 구성 요소를 가지고 있다.



WPF는 위의 그림에서 볼 수 있듯이 XAML(Extensible Application Markup Language)
와 C#과 같은 언어로 구성되어 있다.
XAML은 UI를 구성하는 XML의 일종으로 WPF에서 UI의 모든 부분을 담당하고 있다.
UI를 XAML로 구성하면서 UI에 대한 관리가 좀더 직관적으로 변하였고 융통성 있게
관리할 수 있는 장점이 생겼다.

Markup tag로 애플리케이션 구축 할 수 있게 되였고 단순한 명시적 선언구조에
어떤 CLR 객체 구조 표현 가능해 졌다. 또 코드와 내용의 효과적 분리가 되었고
설계자와 개발자 사이의 협업과 동시작업이 가능하다.

XAML로 구성된 UI의 실제 기능은 C#, VB.NET, Java Script등으로 구성할 수 있다.

WPF의 핵심 구성요소로 다음과 같은 내용들을 제공해 준다.
-탐색, 윈도우, 대화상자에 대한 지원
-UI Data binding, 확장 layout 및 풍부한 control objects,
-2D와 3D 그래픽, Animation, Media, Document

엄청나지 않은가 기본적인 폼 이외에도 각종 Media와 2D, 3D 그래픽까지 모두 다룰
수 있게 되었기 때문에 위의 데모 동영상에서 본 것과 같은 화려한 화면을 구상할
수 있게 된 것이다.

또 WPF는 기본적으로 아래와 같이 OS를 지원할 예정이다.

-Windows의 다음 버전인 Vista에 포함예정
-Windows XP SP2와 Windows Server 2003 SP1에는 WinFX 런타임의 일부로 제공될 예정
-Windows Presentation Foundation Everywhere(WPF/e)
  XAML과 Javascript에 기반을 둔 WPF의 mobile version
  3D 기능은 제공되지 않음, 그러나, XPS, vector-based drawing,
  hardware acceleration은 제공

위의 내용을 정리해 보면 WPF는 Vista 부터 본격적으로 지원이 되지만
Windows XP나 Windows 2003에서도 그 기능을 사용할 수 있다. 또한 Web Application과
Windows Application을 공통적으로 개발할 수 있는 기반이 된다.

이 비슷한 기술들이 이미 RIA(Rich Internet Application)라는 이름으로 나와 있는
제품들도 많이 있다. 가장 대표적인 재품은 Adobe사의 Flex가 그 예이다.
하지만 Flex은 현재 몇가지 치명적인 문제점들이 보이는데
디자이너와 개발자의 협업과 성능, 보안 문제들이 존재한다.

디자이너와 개발자의 협업은 보통 일정 규모 이상의 프로젝트에서 사용하는 형상관리
툴인 CVS나 Visual Source safe, Team System 중에서 CVS만 지원하고 있으며 이는
규모 있는 Project의 운영에 치명적인 약점으로 작용한다.

둘째 성능상의 문제는 Flex는 모든 화면 처리를 CPU가 직접 계산하고 있기 때문에
화면 해상도가 높아지고 Control수와 Effect가 많아지면 화면이 끊기고
CPU점유율이 100%를 상위하는 경우를 쉽게 볼 수 있다.
처리 결과를 보여주어야 할 화면이 처리를 못하게 CPU를 점유하는 아이러니가 남게
되는 것이다.
또 아직은 성능과 보안적인 이슈를 않고 있기 때문에 비교적 데이터양이 적은
영화 예약과 같은 곳에 한정적으로 활용되고 있다.
그럼 WPF의 경우는 어떠한가 WPF는 형상관리 툴을 적극적으로 활용할 수 있으며
Microsoft에 제공하는 개발도구들은 모두 Team System과 Visual Source Safe를 활용 할
수 있게 되어 있다. 또한 WPF는 일반적으로 우리가 3D 가속 칩으로 알고 있는 GPU를
활용할 수 있게 되어 있다. 이는 CPU의 부하를 획기적으로 줄여주면서 더 매끄럽고
화려한 효과를 줄 수 있다. (Nvidia 혹은 ATI의 제품들이 소위 말하는 GPU)이다.

아직 보안과 성능에 관련한 이슈에 대한 답은 아직 WPF라도 처리 방법을 지금은 테스트
해보지는 않았으나 나름 방법은 있을 것이라 기대하고 있다.

WPF를 이용하기 위한 개발환경을 구성하기 위해서는 무엇이 필요한가?
WPF는 WinFX의 한 부분이며 따라서 WPF를 설치하고 테스트 해보기 위해서는 WinFX 개발환경을
구성해야 한다. WinFX의 개발환경을 구성하기 위해서는 설치할 것도 많다.
하지만 WinFX가 정식 발표 되었을 때는 개발도구에 모두 통합되어서 간단히 설치 할 수도
있을 것 같다. WinFX를 사용하기 위해서 설치해야 되는 목록과 순서는 아래와 같다.

이 순서는 친절한 성철씨가 3일간 삽질한 결과로 올려 놓은 것이라 한다.
이 자리를 빌어서 감사의 말씀을 드립니다.
http://lovewiz.pe.kr/31

1. Windows XP SP2 or Windows Server 2003 SP1 설치된 깨끗한 컴퓨터
(Windows Vista도 가능)

2. WinFX Runtime Components 다운로드 및 설치
http://msdn.microsoft.com/windowsvista/downloads/getthebetaaspx?FamilyId=AD0CE56E-D 7B6-44BC-910D-E91F3E370477&displaylang=en

3. Visual Studio 2005 설치

4. Windows SDK 다운로드 및 설치
http://www.microsoft.com/downloads/details.aspx?FamilyId=9BE1FC7F-0542-47F1-88DD-61E3EF88C402&displaylang=en

5. Visual Studio Extensions for WinFX 다운로드 및 설치
http://www.microsoft.com/downloads/details.aspx?FamilyId=AD0CE56E-D7B6-44BC-910D-E91F3E370477&displaylang=en

6. Interactive Designer 다운로드 및 설치(Option)
http://www.microsoft.com/downloads/details.aspx?familyid=D0161985-AE53-4794-9860-61A4906587F0&displaylang=en

Windows SDK를 설치하고 나면 C:\Program files\Windows SDKs\ 하위에 Sample code가 있으며
Sample code를 통해서 전체적인 모습을 보실 수 있다.

김영욱 Microsoft MVP
blog: blog.naver.com/microsoftMVP

Web: www.winkey.pe.kr

email: iwinkey@Hotmail.com

1. Introduction
 

닷넷은 GDI+의 지원으로 더욱더 강력한 웹페이지를 만들어 낼수 있다고 생각한다. 이번 아티글은 동적으로 저장된 데이터를 가지고 바로 Line으로 표현하는 LineChart를 만들어 보고자 한다.

2. Code

Line Chart클래스의 클래스이다. 현재 Current페이지의 ContentType 를 Image/jpeg로 설정한후 바로 브라우저에 그래픽을 뿌려지게 된다. 내부의 코드를 따로 설명하지 않아도 주석을 보면 코드를 충분히 이해 할수 있을것이다.

class LineChart

{

    public Bitmap b;

    public string Title="Default Title";

    public ArrayList chartValues = new ArrayList();//데이터저장

    public float Xorigin=0, Yorigin=0;

    public float ScaleX, ScaleY;

    public float Xdivs=2, Ydivs=2;

    private int Width, Height;

    private Graphics g;

    //데이터 구조체

    struct datapoint

    {

        public float x;

        public float y;

        public bool valid;

    }

    //생성자,초기설정

    public LineChart(int myWidth, int myHeight)

    {

        Width = myWidth; Height = myHeight;

        ScaleX = myWidth; ScaleY = myHeight;

        b = new Bitmap(myWidth, myHeight);

        g = Graphics.FromImage(b);

    }

    public void AddValue(int x, int y) //데이터를 저장한다.

    {

        datapoint myPoint;

        myPoint.x=x;

        myPoint.y=y;

        myPoint.valid=true;

        chartValues.Add(myPoint);

    }

    public void Draw() //그리기

    {

        int i;

        float x, y, x0, y0;

        string myLabel;

        Pen YellowPen = new Pen(Color.Yellow,1);

        Brush YellowBrush = new SolidBrush(Color.Yellow);

        Font axesFont = new Font("arial",10);

        //먼저 이미지 사이즈와 초기화 지역을 잡는다.

        HttpContext.Current.Response.ContentType="image/jpeg";

        g.FillRectangle(new

            SolidBrush(Color.Black),0,0,Width,Height);

        int ChartInset = 50;

        int ChartWidth = Width-(2*ChartInset);

        int ChartHeight = Height-(2*ChartInset);

        g.DrawRectangle(new

            Pen(Color.Yellow,1),ChartInset,ChartInset,ChartWidth,ChartHeight);

        //위에서 설정한 Chart제목을 그린다.

        g.DrawString(Title, new Font("arial",14), YellowBrush,Width/3, 10);

        //X축 좌표 그리기

        for(i=0; i<=Xdivs; i++)

        {

            x=ChartInset+(i*ChartWidth)/Xdivs;

            y=ChartHeight+ChartInset;

            myLabel = (Xorigin + (ScaleX*i/Xdivs)).ToString();

            g.DrawString(myLabel, axesFont, YellowBrush, x-4,

                y+10);

            g.DrawLine(YellowPen, x, y+2, x, y-2);

        }

        //Y축 좌표 그리기

        for(i=0; i<=Ydivs; i++)

        {

            x=ChartInset;

            y=ChartHeight+ChartInset-(i*ChartHeight/Ydivs);

            myLabel = (Yorigin + (ScaleY*i/Ydivs)).ToString();

            g.DrawString(myLabel, axesFont, YellowBrush, 5, y-6);

            g.DrawLine(YellowPen, x+2, y, x-2, y);

        }

        //시작점을 0,0으로 설정한다.

        g.RotateTransform(180);

        g.TranslateTransform(0,-Height);

        g.TranslateTransform(-ChartInset,ChartInset);

        g.ScaleTransform(-1, 1);

        //데이터를 그래프로 표혀한다.

        datapoint prevPoint = new datapoint();

        prevPoint.valid=false;

        foreach(datapoint myPoint in chartValues)

        {

            if(prevPoint.valid==true)

            {

                x0=ChartWidth*(prevPoint.x-Xorigin)/ScaleX;

                y0=ChartHeight*(prevPoint.y-Yorigin)/ScaleY;

                x=ChartWidth*(myPoint.x-Xorigin)/ScaleX;

                y=ChartHeight*(myPoint.y-Yorigin)/ScaleY;

                g.DrawLine(YellowPen,x0,y0,x,y);

                g.FillEllipse(YellowBrush,x0-2,y0-2,4,4);

                g.FillEllipse(YellowBrush,x-2,y-2,4,4);

            }

            prevPoint = myPoint;

        }

        //바지막으로 객체를 저장하여 브라우저에 뿌려준다.

        b.Save(HttpContext.Current.Response.OutputStream, ImageFormat.Jpeg);

    }

    //소멸자

    ~LineChart()

    {

        g.Dispose();

        b.Dispose();

    }

}

아래는 클래스를 생성하여 적용하는 예제이다. Title과 x,y의 Scale을 설정한다. 그리고 데이터를 ArrayList배열에 추가하면 간단한 차트 그래프가 완성된다.

private void Page_Load(object sender, System.EventArgs e)

{

    //객체 생성하기

    LineChart c = new LineChart(640, 480);

    //차트의 크기를 설정한다.

    c.Title="Hoons Line Chart (ASP.NET GDI+)";

    c.Xorigin=0; c.ScaleX=500; c.Xdivs=5;

    c.Yorigin=0; c.ScaleY=1000; c.Ydivs=5;

    //임의의 데이터를 넣는다.

    c.AddValue(50,50);

    c.AddValue(100,100);

    c.AddValue(200,150);

    c.AddValue(450,450);

    //메모리에 그려서 브라우저로 전달한다.

    c.Draw();

}

3. 정리

LineChart가 가장간단히 프로그램 할수 있는 그래프인것 같다. 다음에 기회가되면 원이나 막대 Chart 클래스를 만들어 아티글로 올려 보도록 하겠다.

월간 마이크로소프트웨어 2006년 11월호에 기고한 기사입니다.

보통 프레임워크라고 하면 자바 기반의 다양한 프레임워크를 떠올리기 십상이지만, 최근에는 닷넷 버전으로 컨버전 되는 경우도 종종 보게 된다. 프레임워크의 중요도가 높아짐에 따라 MS는 닷넷 프레임워크 3.0도 모습을 거의 갖춘 상태이다. 또, 지난해에는 한국 MS 단독으로 microsoft.Framework를 무료 공개하기도 했다. 어쩌면 머지않아 더 다양한 닷넷 기반 프레임워크들을 만나게 될 지도 모를 일이다.

닷넷 프레임워크의 활용 전략에 대해 알아보기 전에 프레임워크가 무엇인지에 대해 다시 정의해 보자. Gof의 디자인 패턴으로 유명한 랄프 존슨(Ralph Johnson)은 프레임워크를 다음과 같이 정의했다.

“A framework is a set of cooperating classes that make up a reusable design for a specific class of software”
“프레임워크란 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 클래스들의 집합”

랄프 존슨의 정의에서 알 수 있듯이 프레임워크의 핵심은 재사용성에 있다. 재사용 가능하도록 클래스들을 설계해서 만들어야만 프레임워크라 부를 수 있는 것이다. 이러한 재사용성은 추상화를 전제로 한다. 그렇다면 라이브러리와는 어떻게 구별할 수 있을까? 라이브러리는 특정 기능을 구현하는데 중심을 둔 반면에, 프레임워크는 이러한 기능 문제를 해결한 라이브러리를 조합하여 실제 문제 해결에 중심을 두고 만든 것이라고 이해하면 쉬울 것이다.
프레임워크는 보는 관점 따라서 다양한 분류 방법이 있다. 닷넷 프레임워크 같은 것을 보통 벤더 프레임워크(Vendor Frame work)라고 분류한다. MS라는 벤더 사에서 만들었기 때문이다. 잘 사용되지는 않지만 썬마이크로시스템즈에서도 자바 기반의 JATO(Sun One Application Framework)라는 벤더 프레임워크를 만들어 배포하고 있다.
닷넷 프레임워크는 그 자체로 하나의 훌륭한 프레임워크이다. 하지만 이 닷넷 프레임워크만 가지고 애플리케이션을 만드는 경우는 흔치 않다. 대부분 애플리케이션 성격에 맞는 프레임워크를 미리 준비해서 그 프레임워크 위에서 개발을 하게 된다. 따라서 닷넷 프레임워크는 프레임워크의 프레임워크라고도 할 수 있다. 프레임워크는 그 자체로 완성된 작품이 아니며, 업무에 따라 프레임워크 위에 또 다른 프레임워크를 올려서 더욱 추상화된 형태로 사용할 수도 있는 것이다.

<그림1>닷넷 개발 아키텍처

프레임워크가 필요한 이유?

프레임워크가 필요한 이유를 한마디로 요약하자면 바로 생산성이다. 프레임워크 없이 프로젝트를 한다면 같은 기능을 수행하는 서로 다른 버전의 코드가 존재할 것이고, 매번 똑같은 일을 수행하는 코드가 Copy&Paste 방식으로 차용될 것이다. 또, 개발자의 실력에 따라 천차만별로 달라지는 코드를 통해서 유지보수의 어려움도 느낄 것이다. 새로운 환경이나 변화에 따라 코드를 다시 다 뒤집어 업는 경우도 발생할 것이며, 개발자들이 개발한 코드를 정말 잘 만들었는지 검수할 방법조차 막막해 질 것이다. 정형화된 프레임워크를 사용하면 표준화된 코드들을 생산해 낼 수 있으며, 이를 통해서 생산성을 향상 시키고 좋은 품질의 코드를 만들어 낼 수 있는 것이다.

MS와 프레임워크의 역사

기업용 애플리케이션 환경에서 그동안 자바 진영이 두각을 나타내온 만큼 자바 진영에는 수많은 오픈 프레임워크가 존재 한다. 오히려 너무 많아서 무엇을 선택해야 할지 행복한 고민에 빠지기도 한다. 하지만 닷넷 진영에서는 선택할 수 있는 프레임워크가 많지 않다. MS는 과거 클라이언트 기반의 윈도우나 오피스와 같은 패키지 소프트웨어에서 두각을 나타내었지만, 서버 기반의 기업용 애플리케이션은 자바 진영이 두각을 나타내고 있었다. MS는 이러한 기업용 시장에서는 후발 주자였으며, 패턴이니 프레임워크니 하는 용어 자체가 MS내에서는 익숙하지 않은 용어였다. 하지만 근래에 들어 이러한 기업용 시장에 눈을 뜬 MS는 기업용 서버 기반의 애플리케이션을 제작하는데 있어 개발 방법론, 패턴, 개발 프레임워크를 정리하기 시작했다. 그렇게 해서 만든 사이트가 MS의 패턴 앤프렉티스 사이트이다(http://msdn. microsoft.com/practices). 이곳에 가면 아키텍처에서부터 라이브러리까지 상세한 가이드라인을 얻을 수 있다.

프레임워크를 위한 엔터프라이즈 라이브러리

보통 프로젝트를 한다고 하면 개발에 앞서 프레임워크를 준비하게 된다. 회사에서 자체적으로 만들어둔 표준 프레임워크가 있다면 그것을 사용할 것이다. 만약, 자체 프레임워크가 없다면 일단 프레임워크부터 만들어야 프로젝트를 시작할 수 있다. 하지만 프레임워크를 처음부터 만든다는 것은 그리 쉬운 일이 아니다. 프레임워크를 만드는 것은 아주 많은 시간과 노력을 필요로 하는 작업이다. 때문에 대부분의 경우 프레임워크를 처음부터 만드는 대신 다른 프레임워크를 가져다가 그 위에 자사의 고유한 특징들을 추가하여 사용하게 마련이다. 또, 다른 라이브러리들을 조합해서 자사의 프레임워크로 만들어 사용하기도 한다.

MS는 이처럼 복잡한 프레임워크 개발을 돕기 위해 엔터프라이즈 라이브러리(Enterprise Library)라는 프레임워크를 내놓았다. 엔터프리이즈 라이브러리는 프레임워크를 위한 종합 선물 세트 같은 것이다(엔터프라이즈 라이브러리는 이미 본지 2006.7 ~8월호에 소개가 되었으니 자세한 내용은 과월호를 참조하길 바란다). 엔터프라이즈 라이브러리 2.0은 다음과 같이 여섯 개의 블록으로 구성된다.

● 캐싱 애플리케이션 블록(Caching Application Block)- 로컬 캐시 처리를 위한 블록
● 암호 애플리케이션 블록(Cryptography Application Block)- 해시 함수와 동기 암호화를 위한 블록
● 데이터 액세스 애플리케이션 블록(Data Access Application Block)- 표준화된 데이터베이스 액세스 기능을 위한 블록
● 예외 처리 애플리케이션 블록(Exception Handling Application Block)- 아키텍처 레이어 전체를 포함하여 일관된 예외 처리 정책 수립을 위한 블록
● 로깅 애플리케이션 블록(Logging Application Block)- 로깅 정보 처리를 위한 블록
● 보안 애플리케이션 블록(Security Application Block)- 권한 검증과 보안 캐시 처리를 위한 블록

엔터프라이즈 라이브러리의 블록은 많이 사용되는 기능들을 유형별로 구분해 놓은 것이라고 생각하면 된다. 엔터프라이즈 라이브러리는 소스 코드까지 다 제공하기 때문에 개발자들이 자신의 업무나 현장에 맞도록 블록을 재구성하여 새로운 프레임워크로 만들 수도 있다. 즉, 필요 없는 기능은 제거하고 더 필요한 기능은 추가해서 맞춤형 프레임워크를 만들 수 있도록 도와주는 라이브러리인 것이다.

엔터프라이즈 라이브러리의 각 블록들은 사실 하나 하나가 프레임워크라고도 할 수 있다. 로깅 프레임워크, 보안 프레임워크로 불릴 수도 있다. 왜냐하면 이들 블록은 각각, 재사용성을 가지고 있고, 로깅 및 보안과 같은 해당 업무를 총괄하는 기능을 모두 가지고 있는 까닭이다. 따라서 이들을 프레임워크 분류상으로 기능 프레임워크(Fuctional Framework)라고도 부른다. 단위 테스트 도구인 JUNIT의 닷넷 버전인 NUNIT 또한 단위 테스트 프레임워크라고도 부를 수 있다. 하지만 MS에서는 프레임워크라는 용어 대신 좁은 범위로 묶어서 라이브러리라는 용어를 채택하였다. 그 의도를 알 수는 없으나, 향후 이러한 라이브러리를 묶어서 어떤 상위 개념의 프레임워크의 등장을 염두에 두고 한 것이 아닌가라고 개인적으로 추측을 해 보았다.

엔터프라이즈 라이브러리의 가장 큰 특징은 설정 부분을 별도의 외부 파일로 노출하였다는 점이다. 그 덕에 환경이 바뀌더라도 다시 컴파일 할 필요 없이 환경 설정 파일만 변경해 주면 된다. 예를 들어 DB로 SQL Server를 사용하다가 Oracle로 바꾸었다든지, 암호화 방식을 AES방식에서 DES방식으로 변경해야 한다면, 소스 코드를 수정하지 않고 환경 파일의 내용만 변경하면 된다. 또 다른 특징으로는 성능 카운터 측정을 위한 도구를 제공한다는 것이다.

예를 들어 해당 애플리케이션의 반응 속도가 너무 느려졌는데, 어디에서 원인이 있는지 찾아보려고 할 때, 성능 카운터를 돌려서 어느 부분에 부하가 있는지 알아 볼 수 있다. 이처럼 다양한 기능을 가진 라이브러리를 제공하므로 이를 적절히 조합해서 해당 분야에 맞는 프레임워크를 만들 수 있다.

MS코리아의 자체 프레임워크 Microsoft.Framework

지난 12월 MS코리아에서는 닷넷 엑스퍼트라는 회사에서 개발하여 사용해 오던 닷넷 기반의 개발 프레임워크인 DxFrame work를 인수했다. 또, 이 프레임워크를 공개용 버전으로 만들어서 Microsoft.Framework라 이름을 붙이고 MS 개발자 사이트인 MSDN에서 무료로 배포하고 있다.
(http://www.microsoft.com/Korea/MSDN/netframework/technologyinfo/overview/netdevelopmentguid.aspx)
DxFramework은 처음에 반복되는 데이터 액세스 코드 부분을 간소화하기 위해 라이브러리로 묶은 것이었으나 점점 다른 기능들을 추가 하면서 프레임워크 형태로 발전한 것이다. 위 사이트에는 이 개발 프레임워크 외에도 닷넷 기반의 개발 방법론까지 공개하고 있으므로 관심 있는 독자는 한번 다운로드 받아서 보길 바란다.

Microsoft.Framework의 활용

공개된 Microsoft.Framework는 닷넷 1.1 버전의 프레임워크이다. 여기서 소개된 Microsoft.Framework는 닷넷 익스퍼트라는 회사에서 만든 DxFramework의 Lite 버전이다. 하지만 닷넷 익스퍼트에서 현재 상용으로 판매하고 있는 DxFramework와는 전혀 다른 프레임워크임을 알아두자. 다운로드는 앞에서 언급한 URL에서 프레임워크 설치파일을 다운받을 수 있을 것이다. 모두 한글 기반으로 작성된 프레임워크인 덕에 누구나 쉽게 설치하여 사용할 수 있다.

Microsoft.Framework 설치

설치 프로그램을 다운로드 받은 뒤에 ‘Microsoft.Framework Setup.msi’라는 파일을 실행하면 자신이 원하는 폴더에 프레임워크를 설치할 수 있다.

<화면 1> Microsoft.Framework의 설치화면

설치를 하게 되면 해당 폴더에 Bin과 Source라는 폴더가 만들어 진다. Bin 폴더에는 컴파일 된 프레임워크 dll 파일이 생성되고, Source 폴더에는 Microsoft.Framework를 구성하고 있는 소스와 솔루션 파일들이 만들어지게 된다.

<화면 2> Microsoft.Framework의 소스파일

<그림 2>는 Microsoft.Framework의 구조와 주요한 네임 스페이스의 기능을 정리한 것이다. Microsoft.Framework는 크게 네 가지 기능을 가지고 있다. 첫 번째 기능인 Microsoft. Framework. Configuration은 xml 형태를 가진 계층적 구조를 가진 config 파일 내용을 읽어 오기 위해 사용된다. Microsoft. Framework.Data는 SQL 데이터베이스를 연결을 위한 Microsoft.Framework의 핵심 기능이다.
Microsoft.Framework. Diagnostics는 애플리케이션 실행 중 발생하는 에러를 기록할 때와 컴포넌트의 실행시간을 체크하기 위해서 COM+의 JITA 속성과 결합해서 사용되는 기능이다. 마지막 기능인 Microsoft. Framework.Utility는 스트링이나 파일의 조작을 보다 쉽고 편하게 하도록 지원된다.

샘플 프로젝트 설치

Microsoft.Framework는 샘플 프로젝트를 제공하고 있다. 이 프로젝트를 설치하면 3계층 기반의 사이트를 볼 수 있을 것이다. 또한 가장 중요한 프레임워크 매뉴얼도 볼 수 있기 때문에 이 샘플 프로젝트는 반드시 설치하여 확인해 보아야 한다. Microsoft. Framework는 다음과 같은 디자인 목표를 가지고 있다.

<그림 2> Microsoft.Framework의 구조

● 가급적이면 컴포넌트나 컨트롤 형식으로 작성하여 디자인 타임 지원 기능을 가지도록 한다.
● 런타임 시에 필요한 정보는 속성이나 메소드의 매개 변수로 전달받기 보다는 구성 파일이나 스택 정보에서 읽어내도록 하여 사용을 간편하게 한다.
● 초기화 및 정리 작업이 지능적으로 이루어지도록 하여 되도록이면 작성해야 하는 코드 량을 줄일 수 있도록 한다.
● 구성 파일에서 다양한 동작 특성을 지정할 수 있도록 하여 별도의 커스터마이징 작업이 필요하지 않도록 한다.
● 닷넷 프레임워크와 흡사한 네임스페이스 구조를 가지도록 하여 직관적으로 해당 클래스가 어떠한 역할을 하는지 알 수 있도록 한다.

Microsoft.Framework 샘플 소스의 버전은 닷넷 1.1 버전이다. 이 코드를 VS.NET 2005 환경에서 실행하고 싶다면 Visual Studio 변환 마법사를 통해 쉽게 컨버팅 할 수 있다.

<화면 3> Viusal Stuio 변환 마법사

이 샘플은 DB는 SQL2000에 기본으로 들어 있는 Northwind DB 스키마를 사용하며 내용을 한글화 한 것이다. MS 한글 오피스 프로그램의 액세스에도 샘플로 제공된다. 샘플에서 제공하고 있는 데이터베이스의 스키마는 <화면 4>와 같다.
이 샘플의 특징 중 하나는 모든 웹 페이지는 BaseClass/PageBase를 상속 받고 있다는 것이다. PageBase는 OnInit 오버라이딩 메소드에서 자신의 Content를 화면에 나타내기 전에 Table과 함께 Top Control을 먼저 출력시킨다. 나중에 자신의 Content를 지정된 TD 안에 출력시킨다. <리스트 1>은 이와 관련된 예제 코드이다.

<화면 4> Northwind DB스키마

<리스트 1> BaseClass/PageBase 상속 예제

override protected void OnInit(EventArgs e)
{
base.OnInit(e);
if ( HttpContext.Current == null )
{
return
}
foreach ( Control ctl in Controls )
{
if ( ctl is System.Web.UI.HtmlControls.HtmlForm)
{
_form = ctl as System.Web.UI.HtmlControls.HtmlForm;
}
}
_topMenu = (TopMenu)LoadControl("~/Common/Menu/TopMenu.ascx");
_form.Controls.AddAt(0,_topMenu);
}

Microsoft.Framework.Configuration

앞에서도 잠깐 알아본 것처럼 Microsoft.Framework.Con figuration은 XML 형태의 계층적 구조를 가진 Config 내용을 읽어 오기 위한 기능의 네임스페이스이다. 그 기능을 담당하는 클래스는 AppSettingsReader이다. 만약 어떤 특정한 가변적인 정보를 설정하거나 할 때 Config 파일을 활용해서 설정하면 될 것이다. 물론 Web.Config나 App.Config를 이용해서 특정 정보를 관리 할 수도 있다. 그렇다면 여기서 제공하고 Configuration의 특징은 무엇인가? 다음은 기본 Configuration과 차별된 특징을 보여주고 있다.

● 기본 구성 파일이 아닌 사용자 지정 구성 파일을 사용 할 수 있다.
● 다른 AppDomain의 구성 정보 파일을 기본으로 사용하도록 지정할 수 있다. 이 기능은 서버 활성화를 사용하는 COM+ 클래스에서 편리하게 구성 정보에 접근할 수 있도록 한다.
● 계층적으로 구성된 구성 정보를 사용할 수 있다.
● 지정된 키 값에 해당하는 정보가 없을 경우 디폴트값을 사용할 수 있다.
● 디폴트값의 타입에 맞춰 리턴 값의 타입이 정해지므로 별도의 캐스팅이 필요 없다.
● 구성 정보를 읽는 기본 메소드(GetValue())외에 인덱스를 제공함으로써 호출구문이 간단해진다.

<리스트 2>는 구성 파일을 설정할 때의 예이다.

<리스트 2> AppSettingsReader의 구성파일 설정 예

<configuration>
<Microsoft.Framework>
<AppSettingsReader>
<add key="RaiseException" value="true" />
</AppSettingsReader>

<리스트 3>은 구성 파일을 초기화해서 구성 요소를 불러오는 간단한 예제이다.

<리스트 3> AppSessingsReader 사용 예

AppSettingsReader reader = null
reader = newAppSettingsReader("Microsoft.SampleFramework/ExeTimeLog");
lblExeLogName.Text = reader["LogFileName"];
lblExeTimeEnable.Text = reader["Enable"];

Microsoft.Framework.Data

이 네임스페이스는 SQL 데이터베이스를 연결을 위한 Micro soft.Framework의 핵심 기능을 담당하고 있다. 그 안의 클래스들 중에서도 SqlDbAgent라는 클래스가 가장 대표적인 기능을 하고 있다. 이 SqlDbAgent의 메소드와 사용 예제를 다루어 보도록 하겠다.

<리스트 4>는 가장 많이 사용하게 될 Fill 메소드에 대한 사용 예이다. 데이터를 받아와서 데이터셋에 채우기 위해서는 많은 양의 코드가 필요하지만 Fill 메소드를 사용하면 간단하게 작성할 수 있다.

<리스트 4> Fill 메소드 예제

string query = "GetMessage";
SqlParameter[] paramArray
= {
new SqlParameter("@boardNo", boardNo),
new SqlParameter("@messageNo", messageNo),
new SqlParameter("@step", step)
}

DslBoard ds = new DslBoard();
_agent.Fill(
query,
"Message",
ds,
paramArray,
CommandType.StoredProcedure);
return ds;

SqlDbAgent 클래스의 특징은 다음과 같이 요약할 수 있다.

● DataAdapr, Command 클래스의 자주 사용되는 대부분의 메소드 지원
● 구성 파일을 통한 데이터베이스 연결 문자열 지원
● 다중 데이터베이스 연결 문자열 지원
● 데이터베이스 연결 자원 관리
● 데이터베이스 관련 에러 로깅
● 성능카운터 객체 제공
● COM+ 분산 트랜잭션 및 자동 트랜잭션 지원

SqlDbAgent라는 클래스 말고도 쿼리를 쉽게 작성하기 위한 QueryBuilder나 SqlParameter를 보다 쉽게 조작하기 위한 DbParamHelper라는 클래스가 제공되고 있다. <리스트 5>는 DbParamHelper와 QueryBuilder의 예를 보여주고 있다.

<리스트 5> DbParamHelper와 QueryBuilder 예제

SqlParameter[] paramArray = dataPack.ToSqlParameters();
SqlParamHelper.Add(ref paramArray, "@retVal", SqlDbType.Int);[DbParamHelper의 사용 예]

//DataPack 생성
DataPack dataPack = new DataPack();
dataPack.AddProperty("NavCmd", typeof(int));
dataPack["NavCmd"] = 4;
string name = (string)dataPack["Name"]
//Insert 쿼리 자동생성
QueryBuilder.BuildInsertQuery(dataPack, "테이블이름")[Query Builder의 사용 예]

Microsoft.Framework.Diagnostics

애플리케이션 실행 중에 발생하는 에러를 기록할 때와 컴포넌트의 실행 시 체크하기 위해서 COM+의 JITA 속성과 결합해서 사용되는 기능이다. 에러를 기록하기 위한 클래스로는 ErrorLog 클래스가 구현되어 있으며, 컴포넌트의 실행 시간을 기록하기 위한 클래스로는 ExecutionTimeLog가 구현되어 있다. Execution TimeLog 클래스는 메소드를 실행하기 전에 Prepare 메소드를 실행해서 실행 시간을 기억해 두었다가 특정 처리가 끝난 뒤에 MeasureAndWriteLog 메소드를 호출해서 시간을 기록하게 된다. <리스트 6>은 ExecutionTimeLog의 구성 설정의 예를 보여주고 있다.

<리스트 6> ExecutionTimeLog의 구성 설정

<configuration>
<configSections>
< Microsoft.Framework>
< ExecutionTimeLog >
<add key="Enable" value="true" />
<add key="LogFileName" value="C:\ ExecutionTimeLog .txt" />
</ ExecutionTimeLog >
</ Microsoft.Framework>
</configSections>
<configuration>

ErrorLog 클래스는 WriteLogMessage 메소드를 이용해서 각각의 에러로그를 기록할 수 있다. 에러를 기록하기 위한 보편적인 모델은 각각의 계층에서 가장 상위의 계층으로 Throw해서 Application Error 이벤트를 통해서 에러로그를 기록하는 것이다. <리스트 7>은 에러를 처리하는 예를 보여주고 있다.

<리스트 7> 에러 처리 예

try
{
~~~
}
catch(Exception ex)
{
WriteExceptionLog(ex)
}

Microsoft.Framework.Utility

Utility 네임스페이스 문자열과 파일의 조작을 보다 쉽고 편하게 할 수 있도록 지원하기 위해서 구현한 네임스페이스이다. 하지만 Microsoft.Framework에서의 핵심은 데이터를 엑세스하는 부분이라서 그런지 이 부분의 구현은 조금 미흡하다는 생각이 들 것이다. FileHandler 클래스에서는 바이너리와 텍스트를 불러온다거나 저장하는 메소드를 제공하고 있다. 그리고 StringEx 클래스에서는 원본 문자열 중에서 찾는 문자열의 위치를 얻어내는 메소드를 제공하고 있다. <리스트 8>은 FileHadler를 활용한 예이다.

<리스트 8> FileHadler의 활용 예

//Binary 파일 불러오기
byte[] btData =FileHadler.LoadBinFile("C:\HOONS.JPG")
//Text 파일 불러오기
byte[] btData =FileHadler.LoadTextFile ("C:\HOONS.TXT")
//Text 파일 저장하기
FileHadler.WriteTextFile("C:\HOONS.TXT", "YEAH~Let’s Go")
//Binary 파일 저장하기
FileHadler.WriteBinFile("C:\HOONS.JPG",BinaryData)

프레임워크의 활용

프로젝트를 진행할 때 개발 표준 프레임워크는 필수적이다. 프레임워크는 개발 환경이나 해당 애플리케이션의 업무 환경에 맞도록 맞춤 제작을 하게 된다. 앞에서도 이야기 한 것처럼 보통 이 과정에서는 기본 프레임워크에 맞춤 프레임워크를 올리는 작업을 하게 된다. 이때 중요한 것이 바로 확장성이다. 해당 환경이나 업무가 변화함에 따라 프레임워크도 그에 맞춰 쉽게 변경되거나 확장될 수 있어야 한다. 그래야만 살아있는 프레임워크가 된다. 보통은 공통 표준화팀에서 이러한 개발 프레임워크를 전담하게 되며, 이 팀에서 개발 프레임워크를 기초 설계 환경에 맞도록 만든다. 하지만 프로젝트를 진행 하다보면 처음에 예상하지 못했던 공통적인 기능을 추가하거나 새로운 환경이 추가되는 경우가 많이 발생한다. 이때 이러한 기능을 즉각적으로 개발 프레임워크에 추가하여 개발자들에게 재배포를 해야만 한다. 그렇지 않다면 개발자들은 각각 자신만의 클래스를 만들어서 사용하게 될 것이고, 이러한 일이 계속되면 점점 프레임워크에서 멀어져가게 될 것이다. 즉, 처음에는 모든 기능을 프레임워크에서 찾아서 썼지만 나중에는 점점 자신만의 라이브러리를 추가해서 사용하게 되고 결국 프레임워크에 대한 의존도가 떨어져서 프레임워크를 통한 생산성 향상이나 코드 표준화는 이루어지지 못한다. 가끔 공통 표준화팀의 파워가 강해서 일반 비즈니스 개발자의 이러한 요구 사항을 무시하는 경우가 있다. 이런 사태는 막아야만 한다. 개발 프레임워크는 해당 업무 비즈니스 개발자로부터 끊임없는 피드백을 받아서 수정을 해야만 의존도가 높은 프레임워크로 만들어 질 수 있다. 그래야 비로소 프레임워크를 통한 생산성 향상과 코드 품질의 일관성을 얻을 수 있다.

닷넷 기반 프레임워크의 트렌드

자바 기반의 다양한 각종 프레임워크가 최근 닷넷 버전으로 많이 컨버전 되고 있다. 최근 프레임워크의 특징이라면 관점지향 프로그래밍(Aspect-Oriented Programming)과 IOC(Inversion of Control)기능이라고 할 수 있다. AOP는 업무 비즈니스 개발자가 비즈니스의 요구사항에 집중할 수 있도록 부수적인 기능들은 따로 구현하는 기법을 말한다. 핵심 관심사(core concerns)와 부수적인 횡단 관심사(cross-cutting concerns)로 나누어서 이들을 따로 구현한 다음에 나중에 하나로 합쳐주는 위빙(weaving) 과정을 거쳐 하나의 시스템으로 조립하는 기법이다. 닷넷에 보면 클래스나 함수 위에 기능을 설정하는 속성(attribute)을 지정할 수 있는데, 이 방법 또한 AOP의 한 방법이라고 할 수 있다. IOC는 제어의 반전이라고 번역하는데 이 용어 보다는 의존성 삽입(Dependency Injection)이라는 용어가 더 어울릴 것이다. 이것의 핵심은 이용으로부터 설정을 분리한다는 것이다. 클래스의 재사용성을 높이기 위해서 객체를 사용하는 측에서 만들 것이 아니라, 컨테이너가 설정 정보를 통해서 대신 만들어 주겠다는 개념이다. 이러한 개념들이 자바 진영에서 먼저 시작이 되었고, 이를 이용한 스프링(spring) 프레임워크 등이 닷넷 버전인 Spring. NET으로 발표되고 있다.

MS 닷넷 프레임워크 3.0

얼마 전까지 Ajax에 대한 열기 덕에 Atlas(지금은 Microsoft ASP.NET AJAX)가 개발자들 사이의 화두였다면, 요새는 닷넷 프레임워크 3.0이 개발자들 사이의 최대 관심사이다. 이에 맞춰 닷넷 프레임워크 3.0에 대한 아티클도 점차 올라오고 있고, MSDN 세미나도 줄줄이 열리고 있다.
많은 닷넷 개발자들은 MS의 전략을 따라가면서도 ‘닷넷 프레임워크 2.0이 발표된 지 얼마나 되었다고, 벌써부터 3.0이란 말인가?’라는 의문점을 가지고 있다. 그렇다면 MS는 왜 이렇게 발 빠른 행보를 하고 있는 것일까?




경쟁 대응을 위한 MS의 전략


MS의 민첩한 발걸음은 닷넷 개발자들의 요구 탓이 아니다. 자체적인 혁신에 의한 것 또한 아니다. 전적으로 사업적인 이유에서 이처럼 발걸음을 재촉하게 된 것이다. 예전에도 쟁쟁한 경쟁사들이 있어왔지만, 최근에 들어서는 경쟁 회사의 선전에 밀리는 듯한 모습마저 보이고 있다. 최신 사례로는 Microsoft ASP.NET AJAX가 그렇다. Ajax 열풍에 개발자들이 손쉽게 대처할 수 있도록 개발되었다고 생각하시는 사람들도 있으나(물론 이러한 이유도 내포되어 있다), 보다 현실적이고 근원적인 답안은 사업적인 이유이다(Ajax를 가장 많이 활용하고 있는 개발자들은 대개 자바 진영이고, IBM이 제일 열심히 밀어주고 있다). 닷넷 프레임워크 3.0도 이러한 선상에 있다. 그렇다면 MS는 무엇을 내다보고 있으며, 닷넷 프레임워크 3.0을 통해 얻고자 하는 바는 무엇일까?



MS가 보는 소프트웨어 개발 트렌드


최신 자료에 의하면 MS가 내다보는 소프트웨어 개발 트렌드는 다음과 같다(용어는 필자가 번역하였다).

● 차등화 사용자 경험(Differentiated User Experience)
● 서비스 기반 개발(Service-Oriented Development)
● 비즈니스 프로세스 모델링(Business Process Modeling)
● 디지털 정체성 관리(Digital Identity Management)

누차 강조하지만 Ajax 열풍 이면에는 사용자 경험이 자리 잡고 있다. 기술적인 요소를 떠나 사용자 경험을 향상시키기 위한 대책으로 나온 것이 Ajax이다. Ajax 열풍 이후 많은 기업들이 사용자 경험에 중점을 두고 있으며, MS도 관련 자료를 조금씩 내놓고 있다.
서비스 기반 개발은 프로그래밍 형식이 변해감에 따라 나왔고, 단일 애플리케이션의 설계를 서비스 지향 아키텍처(SOA: Service-oriented architec ture)의 개념을 적용한 개발방법론이다.
비즈니스 프로세스 모델링은 기업의 비즈니스 프로세스를 선진화된 표준 규약을 준수하여 설계하도록 함으로써 프로세스에 대한 명세 및 프로세스가 표출하는 데이터와 연계 지점을 명확하게 하여 프로세스 간의 통합이 가능할 수 있도록 하는데 있다. 작업흐름(workflow)을 대체하는 개념이다.


닷넷 프레임워크 3.0의 구성도


닷넷 프레임워크 3.0의 구성도를 간단하게 표현하면 다음 그림과 같다.
닷넷 프레임워크 3.0은 기존 2.0에 WPF(Windows Presentation Foundation)와 WCF(Windows Communication Foundation), WF (Windows Workflow Foundation) 및 카드 스페이스(CardSpace)를 추가한 형태로 구성되어 있다.
WPF는 UI나 문서 및 미디어를 조합하는 차세대 스마트 클라이언트 응용 프로그램 구축을 위한 클래스를 제공한다. WCF는 서비스 지향 응용 프로그램 구축을 위한 통합 프로그래밍 모델 및 런타임을 제공한다. 또, WF는 비즈니스 프로세스를 모델링하는 워크 플로우에 사용 가능한 응용 프로그램 구축을 위한 프로그래밍 모델과 엔진 및 도구를 제공한다. 마지막으로 카드 스페이스는 개인 ID 정보를 이용한 온라인 작업에 대한 보안을 단순화하고 강화하는 기술을 제공한다.
이건 무엇을 뜻할까? 소프트웨어 개발 트렌드와 닷넷 프레임워크 3.0 구성이 무슨 관계일까? 그 답은 닷넷 프레임워크 3.0이 바로 이러한 트렌드에 맞추어져 있다는 것이다. 정리해보면 구성요소 각각은 다음과 같이 대칭 한다.

● WPF => 차등화 사용자 경험
● WCF => 서비스기반 개발
● WF => 비즈니스 프로세스 모델
● 카드스페이스 => 디지털 정체성 관리


트렌드를 읽는 개발자


개발자도 트렌드를 읽을 줄 알아야 한다. 소프트웨어 개발 트렌드가 어떻게 흐르고 있는지 알아야 다가오는 미래에 대비할 수 있고, 하기에 따라 앞서갈 수도 있다. 현재 주어진 업무에 치여 트렌드를 읽을 수 없다면, 당분간은 별 문제가 없겠지만 패러다임이 변화되었을 때에는 여러 어려움을 겪게 된다. 다행히도 MS에서는 이러한 트렌드를 분명하게 인지하게 해주기 때문에 의미하는 바가 무엇인지 알아야 한다.


트렌드에 대비하는 개발자


닷넷 프레임워크 3.0을 보고 ‘이게 뭐야?’하며 다소 실망하시는 사람들도 있지만, 대부분은 ‘어떻게 대비해야 할까?’를 고민하고 있다. 개인적으로도 명확하게 답해 주고 싶지만, 아쉽게도 아직까지는 그럴 수 없다. 필자 자신도 각 사항에 대해서 고민해보는 시간들을 가져야 한다. 그럼에도, 긍정적으로 권면할 수 있는 것은 닷넷 프레임워크 3.0은 소프트웨어 개발 트렌드를 반영하여 바람직한 방향으로 나아가고 있다는 점이다. MSDN과 세미나 등 다양한 방법을 통해 자료들이 나오고 있기 때문이다. 아직은 대비할 시간이 충분하다. 심적으로 부담스러워하지 말고, 조금씩 하지만 꾸준히 닷넷 프레임워크 3.0의 세계로 나아가보자.
그럼 여기에서 Microsoft ASP.NET AJAX(“Atlas”)는 어떻게 되냐고? ASP.NET 2.0에 통합되므로, 닷넷 프레임워크 3.0에서는 추가적인 설치 없이도 사용 가능하다는 것이 답이다.

이광수 webwings@gmail.com｜FOA(Foundations of Atlas) 번역을 끝내고, 그간 즐기지 못한 여유를 즐기는 중이다. 최근 영화 ‘라디오 스타’와 ‘타짜’를 보고 프로의 세계에 대해 다시 생각해보고 있다. 당분간은 Microsoft ASP.NET AJAX에 대해 더 고민해보고, 점차적으로 닷넷프레임워크 3.0으로 범위를 넓힐 계획을 가지고 있다.

출처 : Tong - 김굽다불낸뇬님의 DotNET Framework/SDK통

사용자 컨트롤 및 사용자 지정 웹 파트로 포털 개인 설정

포털 응용 프로그램은 현재 매우 널리 사용되고 있으며, 뛰어난 포털 응용 프로그램에는 몇 가지 공통점이 있습니다. 실용적인 포털에서는 모듈식의 일관성 있고 탐색이 용이한 사용자 인터페이스를 통해 다양한 콘텐츠가 제공됩니다. 보다 복잡한 포털에서는 사이트 구성원이 콘텐츠를 직접 작성하고 문서를 업로드하며 포털 페이지를 개인 설정할 수도 있습니다.

Microsoft에서는 Windows SharePoint Services를 출시하면서 Windows Server™ 2003 플랫폼에 확장 가능한 포털 프레임워크를 추가했습니다. SharePoint Services에서는 사이트 멤버십 지원, 콘텐츠 및 문서 관리, 웹 파트 사용을 통한 모듈식 데이터 표시 등을 포함하여 포털 프레임워크에 필요한 기본 요소를 제공합니다.

웹 파트는 사용자 지정 및 개인 설정을 수행하기 위한 기초가 됩니다. 또한 사용자는 사이트 구성에 따라 웹 파트를 추가, 재구성 및 제거하여 Windows SharePoint Services의 페이지를 손쉽게 개인 설정하거나 사용자 지정할 수 있습니다. 사용자 지정 웹 파트를 개발하면 Windows SharePoint Services를 기반으로 하여 사이트를 간편하고도 효과적으로 확장할 수 있습니다. 사용자 지정 및 개인 설정을 지원하는 사용자 지정 웹 파트를 만들려면 사용자 웹 파트 클래스에 속성을 추가하고 몇 가지 특수한 특성을 적용하면 됩니다. Windows SharePoint Services의 웹 파트 인프라에서는 사이트 사용자 지정 및 구성원 개인 설정에 관련된 번거로운 데이터 serialize, 저장 및 검색 작업을 모두 수행합니다.

ASP.NET 2.0에 새롭게 도입된 웹 파트 컨트롤 집합은 데이터 사용자 지정 및 개인 설정의 serialization, 저장 및 검색을 백그라운드로 처리하도록 만들어졌다는 점에서 Windows SharePoint Services의 웹 파트 컨트롤과 비슷합니다. 그러나 ASP.NET의 웹 파트 컨트롤은 SQL Server™ 또는 Active Directory에 밀접하게 결합되어 있지 않다는 점에서 차이를 보일 뿐 아니라 융통성이 뛰어난 이점이 있습니다. 이는 폼 기반 인증을 사용하여 포털 응용 프로그램을 빌드하거나 특정 데이터베이스 솔루션에 얽매이지 않으려는 업체에게 매우 유용한 특성입니다.

그림 1. 모듈식 웹 파트 디자인을 보여 주는 샘플 포털

이 기사에서는 ASP.NET 2.0의 웹 파트를 사용하여 작성한 샘플 응용 프로그램을 살펴봅니다. 이 기사의 주된 목적은 포털 응용 프로그램에 사용할 웹 파트를 개발할 때 발생할 수 있는 중요한 디자인 문제를 설명하는 것입니다. 먼저 ASP.NET 2.0의 새 웹 파트 컨트롤 집합을 사용하는 것과 관련된 기본 개념 및 컨트롤 유형에 대해 알아보겠습니다. 포털의 예는 그림 1을 참조하십시오.

웹 파트 입문

그림 2. 웹 파트 페이지의 일반적인 레이아웃

웹 파트를 호스트하는 페이지를 웹 파트 페이지라고 합니다. 웹 파트 페이지에는 그림 2와 같이 정확히 하나의 WebPartManager 컨트롤 인스턴스와 하나 이상의 WebPartZone 컨트롤이 있어야 합니다. 또한 선택적으로 EditorZone 또는 CatalogZone 컨트롤을 포함할 수 있습니다. WebPartManager 컨트롤의 태그는 .aspx 파일에서 웹 파트 인프라와 연관된 WebPartZone, EditorZone 및 CatalogZone 같은 다른 컨트롤 태그보다 앞에 놓여야 합니다. 웹 파트 페이지의 레이아웃과 모양을 보다 효과적으로 제어하기 위해 HTML 테이블을 사용하여 .aspx 파일 내에 다른 영역을 배열할 수도 있습니다.

다음과 같은 WebPartManager 및 WebPartZone 컨트롤이 포함된 간단한 웹 파트 페이지 예제를 살펴봅시다.

<asp:WebPartManager ID=" WebPartManager1" runat="server" />

<asp:WebPartZone ID="WebPartZone1" runat="server" HeaderText="Zone 1">
  <ZoneTemplate>
       <!-- time to add a Web Part -->
     </ZoneTemplate>
   </asp:WebPartZone>

WebPartZone이 있으면 웹 파트 정의를 사용하여 웹 파트 인스턴스를 만들 수 있습니다. 웹 파트 정의는 다음과 같은 두 가지 방식으로 만듭니다. 첫 번째는 WebPart 클래스에서 상속되는 사용자 지정 클래스를 만드는 것이고, 두 번째는 사용자 컨트롤을 만드는 것입니다. 이러한 두 가지 방법의 장단점은 이 기사의 뒷부분에서는 좀 더 자세히 살펴보겠습니다. 지금은 일단 WebPart에서 파생되는 간단한 클래스를 작성해 봅니다(그림 3 참조).

각 웹 파트 인스턴스는 특정 인덱스에 있는 특정 WebPartZone 내의 특정 페이지에 있습니다. 하나의 WebPartZone에는 여러 개의 웹 파트가 포함될 수 있습니다. 예를 들어 그림 4에는 WebPartZone1이라는 영역 내에 두 개 웹 파트가 있습니다.

그림 4. 특정 영역의 웹 파트

웹 파트는 프로그래밍 방식으로 또는 선언적으로 영역에 추가할 수 있습니다. 잠시 후 파트 카탈로그에 웹 파트를 추가하는 기법에 대해서도 살펴보겠습니다. CatalogPart를 만들고 나면 사용자가 런타임에 WebPartZone에 새 웹 파트를 추가할 수 있습니다.

코드를 사용하여 WebPartZone에 웹 파트를 추가하는 방법은 사용하는 웹 파트 유형에 따라 달라집니다. WebPart에서 상속되는 클래스가 있는 경우 프로그래밍 방식으로 클래스 인스턴스를 만들고 WebPartManager 클래스의 AddWebPart 메서드를 호출하면 됩니다. AddWebPart를 호출하려면 웹 파트 인스턴스, 대상 WebPartZone, 그리고 웹 파트가 대상 영역에서 표시될 인덱스를 지정하는 매개 변수를 전달해야 합니다.

// WebPart 파생 클래스에서 웹 파트 인스턴스를 만듭니다.
WebPart wp1 = new WingtipWebParts.HelloWorld();
WebPartManager1.AddWebPart(wp1, WebPartZone1, 0);(참고: 프로그래머 코멘트는 샘플 프로그램 파일에는 영문으로 제공되며 기사에는 설명을 위해 번역문으로 제공됩니다.)

이와 같이 프로그래밍 방식으로 WebPartZone에 웹 파트를 추가할 수 있습니다. 선언적 방식에서는 웹 파트 페이지의 .aspx 파일 내에 컨트롤 태그를 사용합니다. 사용자가 페이지를 처음 검색할 때 특정 WebPartZone에 웹 파트가 표시되도록 하려면 WebPartZone에 ZoneTemplate을 추가합니다.

<%@ Register Assembly="WingtipWebParts" Namespace="WingtipWebParts"
TagPrefix="Wingtip" %>

<asp:WebPartManager ID=" WebPartManager1" runat="server" />

<asp:WebPartZone ID="WebPartZone1" runat="server" HeaderText="Zone 1">
  <ZoneTemplate>
    <Wingtip:HelloWorld runat="server" id="HelloWorld" />
  </ZoneTemplate>
</asp:WebPartZone>

이 때 몇 가지 내용을 추가하지 않으면 웹 파트 페이지의 웹 파트가 너무 건조해 보일 것입니다. 인트라넷 포털 응용 프로그램에서 일반적으로 요구되는 기능은 사이트에 "스킨"을 적용하여 사용자의 취향에 따라 모양을 바꾸는 기능입니다. 예전에는 이를 위해 직접 인프라를 빌드하여 컨트롤 렌더링 변경을 지원해야 했으며, 여기에는 많은 작업이 수반되었습니다. ASP.NET 2.0에는 "테마"라는 개념이 도입되었습니다. 테마란 개별 컨트롤, 전체 페이지 또는 전역 응용 프로그램 수준까지 적용할 수 있는 스타일 및 컨트롤 특성 모음입니다.

포털 응용 프로그램을 보다 세련되고 전문적으로 만들려면 WebPartZone, EditorZone 및 CatalogZone 컨트롤의 모양을 모두 사용자 지정합니다. 웹 파트, 편집기 파트 및 카탈로그 파트의 본문, 제목 표시줄 및 동적 메뉴가 표시되는 모양에 스킨을 지정하고 사용자의 고유한 특성을 적용해야 하기 때문에 이 작업은 처음에 매우 지루할 수 있습니다. 다행히도 ASP.NET 2.0의 새 테마 기능을 사용하면 .aspx의 시각 효과 작업을 고려하여 다시 사용 가능한 .skin 및 .css 파일에 적용할 수 있습니다. 이 기사의 샘플 포털 응용 프로그램은 스킨 및 테마를 사용하여 웹 파트 모양을 사용자 지정하며, MSDN? Magazine 웹 사이트에서 이를 사용할 수 있습니다.

모드 및 페이지 범위 표시

하나의 WebPartManager 컨트롤 인스턴스가 각 웹 파트 페이지에서 실행되며, 웹 파트 인스턴스 및 해당 인스턴스가 WebPartZone 컨트롤에 관련되는 방식을 관리합니다. 또한 WebPartManager 컨트롤에서 제공하는 프로그래밍 방식 인터페이스를 사용하여 찾아보기, 디자인 및 편집 디스플레이 모드 사이에서 웹 파트 페이지를 전환할 수 있습니다. 예를 들어 프로그래밍 방식으로 현재 페이지를 디자인 모드로 전환하려면 다음과 같이 DisplayMode 속성을 DesignDisplayMode로 설정하는 이벤트 처리기가 있는 링크 컨트롤을 추가하면 됩니다.

WebPartManager1.DisplayMode = WebPartManager.DesignDisplayMode;

또한 웹 파트 페이지의 각 디스플레이 모드별 차이점을 이해해야 합니다. 기본적으로 웹 파트 페이지는 찾아보기 모드에서 작동하며, 이 모드에서 사용자는 웹 파트를 변경할 수 없습니다. 웹 파트 페이지를 디자인 모드로 전환하면 사용자는 WebPartZone 내에서 또는 영역 간에 웹 파트를 이동할 수 있습니다. 그림 5에는 사용 가능한 디스플레이 모드가 나와 있습니다.

ASP.NET 2.0 웹 파트 컨트롤은 필요한 DHTML 및 JavaScript를 백그라운드로 생성하여 브라우저 내에서 끌어서 놓는 작업을 수행할 수 있도록 합니다. 필요한 DHTML 및 JavaSript 기능을 지원하지 않는 브라우저에서도 끌어서 놓기 편집 기능을 제외한 모든 기능을 사용할 수 있습니다. 그렇기 때문에 모든 클라이언트에서 Microsoft Internet Explorer 5.0 이상을 사용하지 않아도 됩니다. ASP.NET 2.0 웹 파트 컨트롤은 또한 개인 설정 데이터의 저장 및 검색 작업을 관리하여 사용자가 이전 세션에서 웹 파트를 배치한 위치를 기억합니다.

WebPartManager에서는 디스플레이 모드 간에 코드를 전환할 수 있는 기능 외에도 사용자 범위 및 공유 범위 간에 웹 파트 페이지를 변경하는 방법을 제공합니다. 페이지 범위에 따라 웹 파트 변경 내용이 사용자 지정인지 개인 설정인지 여부가 결정됩니다. 사용자 지정 변경 내용은 모든 사용자에게 표시되지만, 개인 설정 변경 내용은 해당 변경 작업을 수행한 사용자에게만 표시됩니다. 웹 파트 변경 작업은 다음과 같이 WebPartManager 컨트롤의 ToggleScope 메서드를 호출하여 수행됩니다.

WebPartManager1.Personalization.ToggleScope();

기본 범위는 사용자 범위이며 여기서 웹 파트 변경 내용은 현재 사용자에게만 표시되는 개인 설정으로 기록됩니다. ToggleScope 메서드를 제대로 호출하면 웹 파트 페이지가 공유 범위에 배치되며, 변경 사항이 사용자 지정으로 기록됩니다. 공유 범위의 용도는 관리자나 사이트 디자이너가 모든 사용자에게 표시되는 웹 파트 페이지에서 웹 파트에 대해 사용자 지정 변경 작업을 일괄적으로 수행할 수 있도록 하는 것입니다. 사용자가 수행한 모든 개인 설정 변경 내용이 전역 사용자 지정과 중복되는 경우에는 개인 설정 변경 내용이 항상 우선합니다.

현재 사용자가 항상 공유 범위로 들어갈 수 있는 것은 아닙니다. 기본적으로 공유 범위로 들어가는 데 필요한 권한을 가진 사용자는 없습니다. 공유 범위로 들어가려면 Web.config 파일에서 해당 권한을 부여 받아야 합니다. 다음은 admin 또는 site_designer 역할로 모든 사용자에 대해 공유 범위로 들어가 전역 사용자 지정을 수정할 수 있는 권한을 부여하는 예제입니다.

<webParts>
  <personalization>
    <authorization>
      <allow roles="admin, site_designer" verbs="enterSharedScope" />
    </authorization>
  </personalization>
</webParts>

속성 및 개인 설정

각 웹 파트 개체에는 사용자 지정 또는 개인 설정할 수 있는 표준 속성 집합이 있습니다. 예를 들어 각 웹 파트에는 WebPartZone에 추가한 후 사용자 지정할 수 있는 Title 속성이 있습니다. EditorZone 컨트롤 및 다양한 편집기 파트를 사용하면 사용자가 웹 파트 속성을 변경할 수 있습니다.

사용자가 웹 파트 페이지를 EditDisplayMode로 설정하면 웹 파트 메뉴에 Edit 명령이 제공됩니다. 특정 웹 파트에서 Edit 명령을 호출하면 해당 영역에 배치한 편집기 파트와 함께 EditorZone이 표시됩니다. ASP.NET 2.0에는 표준 웹 파트 모양, 동작 및 레이아웃을 수정하기 위한 여러 개의 편집기 파트가 기본적으로 제공됩니다.

웹 파트 개인 설정 스키마는 개인 설정 가능한 사용자 지정 속성을 추가하여 간편하게 확장할 수 있습니다. 웹 파트 클래스 정의에 속성을 추가하고 Personalizable, WebBrowsable 및 WebDisplayName 같은 특성을 적용하면 됩니다. 이 작업을 완료하고 나면 웹 파트 컨트롤에서 사용자 지정 또는 개인 설정된 속성 값을 저장 및 검색합니다.

사용자 지정 속성을 만들 때는 보통 다음과 같이 개인 필드를 정의합니다.

private bool _HR = true;

[Personalizable(PersonalizationScope.User), 
 WebBrowsable, WebDisplayName("HR 뉴스 표시"),
 WebDescription("이 속성을 사용하여 HR 뉴스 표시/숨김")]
public bool HR 
{
  get { return _HR; } set { _HR = value; }
}

사용자가 이와 같이 속성을 개인 설정할 수 있도록 하려면 PropertyGridEditorPart를 현재 페이지의 EditorZone에 추가하면 됩니다. 그림 6은 이 작업을 수행할 때 사용자에게 표시되는 화면을 보여줍니다.

그림 6. 사용자가 웹 파트를 개인 설정할 수 있는 편집기 파트

문자열 또는 숫자 형식을 기반으로 웹 파트 속성을 정의하는 경우 PropertyGridEditorPart에서는 사용자가 값을 변경하도록 입력란을 제공합니다. 부울 값을 기반으로 웹 파트 속성을 정의하는 경우에는 PropertyGridEditorPart에서 그림 6과 같은 확인란을 제공합니다.

그림 7에는 Windows SharePoint Services를 사용한 웹 파트 개발에서 사용할 수 있는 유용한 프로그래밍 기법이 나와 있어, 해당 유형을 열거 유형을 기반으로 하는 개인 설정 속성을 정의할 수 있습니다.

열거를 기반으로 하는 개인 설정 속성인 WebBrowsable을 만들면 그림 7에서 Timeframe 속성에 대해 표시한 것처럼 PropertyGridEditorPart에서 사용자가 사용 가능한 속성 설정의 드롭다운 목록을 생성하므로 매우 유용합니다. 그러므로 사용자는 편리하게 작업을 수행하고 올바른 속성 값을 선택할 수 있습니다.

Timeframe 속성 정의에 대해서 알아두어야 할 사항이 한 가지 더 있습니다. 이 속성 정의는 PersonalizationScope.Shared 설정이 있는 Personalizable 특성으로 정의되었습니다. 이러한 방식을 사용하여 공유 속성으로 정의된 속성은 사용자 지정할 수 있지만 개인 설정할 수는 없습니다. 공유 속성은 개인 설정에 사용할 수 없으므로 현재 웹 파트 페이지가 사용자 범위에 있으면 해당 속성은 PropertyGridEditorPart에 표시되지 않으며, 페이지가 공유 범위에 있을 때만 표시됩니다.

웹 파트 카탈로그

지금까지 웹 파트를 WebPartZone으로 채우는 웹 파트 페이지를 살펴보았습니다. 이 기법은 사용자가 런타임에 새 웹 파트를 추가하도록 하는 다른 방식을 통해 보다 수준 높게 활용할 수 있습니다. 이러한 작업은 PageCatalogPart 및 DeclarativeCatalogPart 같은 CatalogZone 및 CatalogPart를 사용하여 수행할 수 있습니다(그림 8 참조).

이와 같은 방식으로 CatalogZone 및 CatalogPart를 추가하고 나면 사용자는 그림 9와 같은 사용자 인터페이스를 통해 런타임에 동적으로 웹 파트를 추가할 수 있습니다.

그림 9. 사용자가 동적으로 웹 파트를 추가할 수 있도록 하는 CatalogZone

먼저 PageCatalogPart의 용도를 이해해야 합니다. 디자인 디스플레이 모드 또는 편집 디스플레이 모드에서 사용자는 웹 파트에 대해 Close 명령을 호출할 수 있습니다. 사용자가 웹 파트를 닫으면 나중에 사용자가 해당 WebPart를 다시 추가할 수 있도록 웹 파트 및 개인 설정 또는 사용자 지정 설정이 보존됩니다. 그러므로 PageCatalogPart에는 닫혀 있으며 페이지에 추가할 수 있는 모든 웹 파트 목록이 표시됩니다.

Close 명령은 Delete 명령과는 다릅니다. Delete 명령은 편집 디스플레이 모드에서만 사용할 수 있습니다. 사용자가 웹 파트를 삭제하면 사용자 지정 및 개인 설정 데이터를 포함하여 웹 파트의 존재에 관한 모든 정보가 저장소에서 삭제됩니다.

웹 파트를 사용하여 DeclarativeCatalogPart를 선언적으로 채울 수 있습니다. 그림 8의 코드에서는 사용자 지정 이름의 WeatherWebPart로 이 카탈로그를 채우는 방법을 보여 줍니다. 이 방법을 사용하면 사용자가 모든 종류의 웹 파트를 사용하도록 할 수 있습니다.

이 기사의 내용을 보충하고 웹 파트 페이지 빌드에 대해 보다 자세히 알아보려면 Stephen Walther의 기사인 "Introducing the ASP.NET 2.0 Web Parts Framework"(영문)를 참조하십시오. 이 기사에는 EditorZone 및 CatalogZone을 사용한 웹 파트 페이지 빌드에 대한 보다 자세한 내용과 실제 예제가 나와 있습니다. 또한 Verbs, Connections, 웹 파트 가져오기/내보내기 등 보다 수준 높은 주제에 대해서도 설명하고 있습니다.

ASP.NET 2.0 포털 개발

ASP.NET 2.0에는 WebPart 인프라 자체 외에도 인트라넷 포털 사이트 개발에 필요한 여러 가지 유용한 새 기능이 있습니다. 이 기사 앞부분에서 언급했듯이 테마 및 스킨이 도입되어 포털 페이지에서 스타일 속성을 구분하기가 매우 간편해졌으며, 개별 페이지를 변경하지 않고도 일괄적으로 스타일 변경 사항을 적용할 수 있게 되었습니다. 그러나 보다 맘에 드는 것은 마스터 페이지의 도입입니다. 마스터 페이지를 사용하면 모든 WebPartZone 및 전체 WebPartManager 컨트롤을 단일 템플릿 페이지로 분리할 수 있습니다. 이 템플릿 페이지에서 개별 페이지는 기본 모양 및 기능을 상속합니다. 이 기사의 샘플 포털에서는 마스터 페이지에 있는 각 WebPartZone의 ZoneTemplate 내에 ContentPlaceholder를 추가하는 흥미로운 기법을 사용합니다. 이 방법을 사용하면 해당 마스터 페이지를 사용하는 콘텐츠 페이지는 각각의 ContentPlaceHolder 컨트롤로 매핑되는 Content 컨트롤을 사용하여 자체 웹 파트를 추가할 수 있습니다.

포털 사이트용 마스터 페이지를 디자인할 때 결정해야 하는 사항 중 하나는 사용자가 사용자 지정 기능을 사용할 수 있도록 하는 방법입니다. 앞서 살펴본 것처럼 페이지에 추가하는 영역 유형에 따라 사용자는 다양한 사용자 지정 모드를 선택하여 페이지를 변경할 수 있습니다.

사용자에게 사용자 지정 옵션이 표시되도록 하는 한 가지 옵션은 WebPartManager 컨트롤 및 단추 컬렉션(보통 LinkButton)을 모두 사용자 컨트롤에 래핑하는 것입니다. 그러면 마스터 페이지에 해당 사용자 컨트롤이 추가되어 사이트의 모든 페이지에 대해 사용자 지정 옵션을 제공합니다. 웹 사이트에 마스터 페이지를 두 개 이상 만들려는 경우에는 이러한 컨트롤을 사용자 컨트롤(여기서는 WebPartManagerPanel이라고 함)에 캡슐화하는 방법도 유용합니다. 그러면 페이지의 일부 하위 집합에 대해 대체 레이아웃이 제공됩니다. 앞서 그림 1에서 살펴보았던 응용 프로그램의 메뉴 모음에는 WebPartManager의 현재 모드 및 범위를 표시하는 샘플 사용자 컨트롤이 표시되어 있습니다. 이 샘플 컨트롤에는 또한 페이지 모드를 WebPartManager에서 지원하는 편집 모드 중 하나로 변경하는 LinkButton도 제공됩니다(이것은 샘플 포털 응용 프로그램에서 사용하는 컨트롤임).

WebPartManagerPanel은 현재 사용자 및 페이지를 기준으로 사용 가능한 디스플레이 모드를 동적으로 표시하거나 숨기는 등의 다른 유용한 기능도 제공합니다. WebPartManager의 SupportedDisplayModes 컬렉션을 확인하고 이 정보를 사용하여 해당 모드를 표시하는 메뉴 항목을 설정하거나 해제함으로써 지원되는 디스플레이 모드를 쿼리할 수 있습니다. 예를 들어 현재 페이지에서 CatalogDisplayMode를 지원하는지 여부를 확인하려면 다음을 수행하십시오.

if (WebPartManager1.SupportedDisplayModes.Contains(
    WebPartManager.CatalogDisplayMode)) {
  //여기에 카탈로그 디스플레이 모드 LinkButton 표시
}

또한 적절한 권한이 없는 사용자 컨텍스트 내에서 실행하는 경우 ToggleScope 호출은 실패합니다. WebPartManager 컨트롤의 Personalization 속성이 제공하는 CanEnterSharedScope 속성을 쿼리하는 코드를 제공하여 사용자가 공유 범위로 들어올 수 있도록 하는 사용자 인터페이스 요소를 숨길 것인지 또는 표시할 것인지 여부를 결정하는 것이 좋습니다.

if (WebPartManager1.Personalization.CanEnterSharedScope)  {
  // 사용자가 공유 범위로 들어오도록 하는 UI 요소를 표시합니다.
}

이 기사에 나와 있는 샘플의 WebPartManagerPanel 사용자 컨트롤에는 현재 사용자 및 페이지 기능을 기반으로 디스플레이를 동적으로 조정하는 완전한 패널 구현이 포함되어 있습니다.

웹 파트로서의 사용자 컨트롤

Windows SharePoint Services를 사용하여 웹 파트를 빌드하는 과정에서 혼란을 야기하는 사항 중 하나는, 디자이너 기능은 전혀 활용하지 못하는 상태로 컨트롤의 전체 사용자 인터페이스를 프로그래밍 방식으로 만들어야 한다는 점입니다. 웹 파트는 대부분 상호 작용하는 서버측 컨트롤 컬렉션이기 때문에 웹 파트를 만들 때 Visual Studio 디자이너 기능을 사용하지 못하는 것은 상당히 아쉬운 점입니다. 이 문제를 확실하게 해결하는 방법은 개발자가 ASP.NET 사용자 컨트롤을 만들어 웹 파트로 사용하도록 하는 것입니다. SmartPart라는 타사 도구를 사용하면 사용자 컨트롤을 Windows SharePoint Services의 웹 파트로 적용할 수 있습니다.

ASP.NET 2.0 웹 파트를 사용하면 모든 컨트롤을 수정하거나 래핑할 필요없이 직접 웹 파트로 사용할 수 있으므로 이 문제가 해결됩니다. 이 방법은 사용자 컨트롤을 웹 파트 컬렉션에 통합하는 데 유용할 뿐 아니라, 이를 통해 현재 ASP.NET 페이지용으로 빌드한 사용자 컨트롤을 손쉽게 통합할 수 있습니다.

이 방법은 표준 컨트롤(비웹 파트)이 WebPartZone에 추가되면 WebPartManager.CreateWebPart가 암시적으로 호출되고, GenericWebPart 클래스 인스턴스가 할당되며 추가된 컨트롤을 사용하여 해당 컨트롤을 초기화하는 방식으로 내부적으로 작동합니다. GenericWebPart 클래스는 WebPart 기본 클래스에서 파생되며 핵심 웹 파트 속성 구현을 제공합니다. GenericWebPart가 구성되면 초기화에 사용된 컨트롤이 자식 컨트롤로 추가됩니다. 렌더링을 수행하는 동안 GenericWebPart는 응답 버퍼 자체로는 아무것도 렌더링하지 않으며 대부분의 복합 컨트롤이 그러하듯이 자식 컨트롤에 렌더링을 위임합니다. 그러면 최종적으로 페이지의 WebPartZone에 원하는 컨트롤을 모두 추가할 수 있으며 페이지는 제대로 작동합니다. 예를 들어 다음 페이지에서는 사용자 컨트롤과 표준 Calendar 컨트롤이 있는 WebPartZone을 정의합니다. 사용자 컨트롤과 Calendar 컨트롤은 모두 만들어질 때 GenericWebPart 클래스에 의해 암시적으로 래핑됩니다.

<%@ Register Src="webparts/CustomerList.ascx" 
    TagName="CustomerList" TagPrefix="Wingtip" %>

<asp:WebPartManager ID=" WebPartManager1" runat="server" />

<asp:WebPartZone ID="WebPartZone1" runat="server" HeaderText="Zone 1">
  <ZoneTemplate>
    <Wingtip:CustomerList runat="server" id="CustomerList" />
    <asp:Calendar runat="server" id="CustomerCalendar" />
  </ZoneTemplate>
</asp:WebPartZone>

표준 웹 파트와 마찬가지로, GenericWebPart에 의해 래핑된 컨트롤을 동적으로 만들 수 있습니다. 이 컨트롤이 사용자 컨트롤인 경우에는 Page.LoadControl을 호출하여 사용자 컨트롤 인스턴스를 동적으로 로드하고 만들어야 하며, 그런 다음에는 컨트롤에 고유한 ID를 명시적으로 지정해야 합니다. 그리고 나서 WebPartManager 개체의 CreateWebPart 메서드를 호출하여 GenericWebPart 클래스 인스턴스를 만들어야 합니다. 이 인스턴스는 사용자 컨트롤 인스턴스 주위의 래퍼 역할을 합니다. 마지막으로 CreateWebPart를 호출하여 반환된 GenericWebPart 참조를 가져와 AddWebPart 호출로 전달하여 추가될 WebPartZone을 지정해야 합니다.

// 사용자 컨트롤 파일에서 웹 파트 인스턴스를 만듭니다.
Control uc = this.LoadControl(@"webparts\CompanyNews.ascx");
uc.ID = "wp2";
GenericWebPart wp2 = WebPartManager1.CreateWebPart(uc);
WebPartManager1.AddWebPart(wp2, WebPartZone1, 1);

그림 10. GenericWebPart

이 기술을 사용할 때의 단점은 GenericWebPart 클래스가 컨트롤이 아닌 WebPart에서 상속되는 클래스이기 때문에 컨트롤의 웹 파트 관련 기능을 제어할 수 없다는 것뿐입니다. GenericWebPart에 의해 래핑된 컨트롤이 있는 페이지를 실행해 보면 이 단점을 확실하게 파악할 수 있습니다. 이러한 페이지의 기본 제목은 제목 없음이며 대부분이 웹 파트처럼 아이콘이나 연결된 설명이 없기 때문입니다. 그림 10은 GenericWebPart에 의해 래핑되었으며 기본 제목(제목 없음) 및 아이콘이 지정되어 있는 샘플 사용자 컨트롤을 보여줍니다.

이 문제를 해결할 수 있는 방법은 사용자 컨트롤의 Init 이벤트에 대한 처리기를 추가하는 것입니다. 컨트롤이 GenericWebPart에 의해 래핑된 경우(Parent 속성 유형을 쿼리하여 확인할 수 있음) GenericWebPart 클래스 특성을 다음과 같이 설정해야 합니다.

void Page_Init(object src, EventArgs e) {
  GenericWebPart gwp = Parent as GenericWebPart;
  if (gwp != null)  {
    gwp.Title = "내 사용자 지정 사용자 컨트롤";
    gwp.TitleIconImageUrl = @"~\img\ALLUSR.GIF";
    gwp.CatalogIconImageUrl = @"~\img\ALLUSR.GIF";
  }
}

사용자 컨트롤이 GenericWebPart에 의해 래핑되는 경우 해당 페이지를 다시 실행하면 GenericWebPart 상위 속성에 대해 수행된 변경이 컨트롤이 포함된 웹 파트 렌더링에 반영됩니다. 그림 11은 특성이 새롭게 지정된 사용자 컨트롤을 보여줍니다. 제목과 아이콘을 살펴보십시오.

그림 11. 제목 및 아이콘

또 다른 유용한 해결 방법은 사용자 컨트롤 클래스에서 직접 IWebPart 인터페이스를 구현하는 것입니다. GenericWebPart 클래스에서 세부 작업을 처리하기 때문에 사용자 컨트롤은 웹 파트 속성에 대해 직접 쿼리되지 않아 이 방법은 별로 도움이 되지 않는다고 생각될 수도 있습니다. 다행히도 GenericWebPart 클래스 디자이너들은 이러한 요구 사항을 예상하고 래핑된 컨트롤이 IWebPart 인터페이스를 구현하는 경우 자동으로 해당 컨트롤로 위임되도록 GenericWebPart 클래스의 속성을 구현했습니다.

따라서 사용자 컨트롤의 웹 파트 기능을 사용자 지정하려면 IWebPart 인터페이스를 구현하고 해당 인터페이스가 정의하는 7가지 속성을 채우면 됩니다. 그림 12의 코드에서는 GenericWebPart 속성을 동적으로 변경하여 이전에 수행했던 작업과 같은 결과를 얻을 수 있는 사용자 컨트롤에 대한 코드 숨김 클래스의 예제를 보여 줍니다.

사용자 컨트롤에 대해 대체 기본 클래스를 만들 수도 있습니다. 이 클래스는 UserControl에서 파생되고 IWebPart를 구현하며, 포털의 모든 사용자 컨트롤에서 이 클래스를 상속할 수 있습니다. 이 기사의 샘플 포털 솔루션에서는 이 작업을 수행합니다. 이 솔루션을 사용하면 사용자 컨트롤은 생성자에서 처리되는 속성을 초기화할 수 있으며 나머지는 자체적으로 처리됩니다. 그림 13은 IWebPart를 구현하는 사용자 컨트롤의 대체 기본 클래스와 해당 클래스를 사용하여 제목 및 아이콘 속성을 설정하는 사용자 컨트롤의 해당 코드 숨김 클래스를 보여줍니다.

이와 같이 사용자 컨트롤에 융통성이 높기 때문에 디자이너에서 사용자 컨트롤을 지원하고 WebPart 기능을 사용자 지정할 수 있는데 사용자 지정 컨트롤을 만들 필요가 있느냐는 의문이 생길 수도 있습니다. 실제로 여기에는 여러 가지 이유가 있습니다. 우선, 사용자 컨트롤에는 사용자 지정 verbs를 추가할 수 없습니다. verbs를 추가하려면 WebPart에서 직접 파생시켜 Verbs 속성을 다시 정의해야 합니다. 컨트롤에서 IWebEditable을 구현하는 방법도 고려해 볼 수 있습니다.

또 다른 이유는 사용자 컨트롤의 범위가 기본적으로 응용 프로그램 디렉터리 내라는 점입니다. .ascx 파일을 여러 프로젝트에 실제로 복사하지 않고는 여러 웹 응용 프로그램에서 사용자 컨트롤 구현을 공유할 수 없습니다. 반면 WebPart 클래스에서 파생되는 사용자 지정 웹 파트는 다시 사용 가능한 DLL로 컴파일하여 GAC(전역 어셈블리 캐시)에서 전역으로 배포할 수 있습니다. 또한 사용자 지정 웹 파트를 사용하면 컨트롤에 대해 사용자 지정 디자이너를 작성하여 Visual Studio 내에서 컨트롤의 기본 모양을 변경할 수 있으며, 도구 상자 위로 끌었을 때 웹 파트와 연결될 아이콘을 만들 수 있습니다. 그림 14는 사용자 지정 웹 파트 및 사용자 컨트롤 중에서 선택하는 데 도움이 되는 기능 비교을 보여 줍니다.

웹 파트 및 개인 설정 공급자

공급자는 ASP.NET 2.0의 새로운 기능으로, 이번 릴리스에서 완전한 기능을 갖춰 코드 작성 및 실행 작업이 거의 또는 전혀 필요하지 않은 다양한 컨트롤을 사용할 수 있도록 해줍니다. 공급자의 기본 개념은 특정 기능에 대해 일반적인 데이터 관련 작업 집합을 정의하고 해당 작업을 일반 ProviderBase 클래스에서 상속되는 추상 클래스 선언으로 묶는 것입니다. 이 기사에서는 개인 설정 기능에서 반드시 사용해야 하는 다음 데이터 관련 작업을 살펴봅니다.

• 특정 페이지 및 사용자에 대한 웹 파트 속성 및 레이아웃 저장
• 특정 페이지 및 사용자에 대한 웹 파트 속성 및 레이아웃 로드
• 특정 페이지에 대한 일반 웹 파트 속성 및 레이아웃(일반 사용자 지정의 경우) 저장
• 특정 페이지에 대한 일반 웹 파트 속성 및 레이아웃(일반 사용자 지정의 경우) 로드
• 특정 페이지 및 사용자에 대한 웹 파트 속성 및 레이아웃을 기본값으로 다시 설정
• 특정 페이지에 대한 웹 파트 속성 및 레이아웃(일반 사용자 지정의 경우)을 기본값으로 다시 설정

개인 설정 인프라의 일부이며 지속적으로 필요한 일부 다른 부가 기능도 있지만, 기본적으로는 위의 여섯 가지 기능으로 요약할 수 있습니다. 이러한 여섯 가지 작업을 수행할 수 있으며 데이터를 성공적으로 저장 및 복원할 수 있는 클래스가 있다면, 각 페이지의 WebPartManager는 해당 클래스를 사용하여 사이트가 실행되는 동안 모든 개인 설정 및 사용자 지정 데이터를 저장 및 복원할 수 있습니다. 이러한 메서드를 정의하는 추상 클래스는 PersonalizationProvider이며, 기본적으로 사용되는 이 클래스의 구체적 파생 클래스는 SqlPersonalizationProvider입니다. 앞서 확인한 여섯 가지 기능을 나타내는 세 가지 메서드는 그림 15에 나와 있습니다. 각 메서드는 들어오는 userName 매개 변수가 null인지 여부에 따라 사용자 개인 설정 또는 공유 사용자 지정을 수행할 수 있습니다.

그림 16. 상호 작용

모든 개인 설정 데이터는 단순 이진 데이터(byte[])로 저장되며, 기본 SqlPersonalizationProvider에서 데이터베이스의 이미지 필드에 기록됩니다. ASP.NET 2.0은 이러한 메서드를 제공하는 클래스가 있음을 인지하기 때문에 과거보다 훨씬 많은 논리를 기본 컨트롤 집합으로 빌드할 수 있습니다. 이 기사에서 웹 파트를 사용하는 각 페이지의 WebPartManager는 현재 PersonalizationProvider 클래스를 올바르게 호출하여 각 페이지의 개인 설정 관련 설정을 serialize 및 복원하는 작업을 담당합니다. 그림 16의 다이어그램에서는 EditorZone 컨트롤과 기본 SqlPersonalizationProvider 간의 상호 작용을 보여줍니다.

ASP.NET 2.0을 많이 사용할수록 이러한 공급자 아키텍처의 예제를 많이 확인할 수 있습니다. 구성원, 역할 관리, 사이트 맵 데이터, 상태 모니터링 등 여러 항목에 대한 공급자가 있으며, 이들은 모두 서로 상호 작용할 컨트롤에 대해 비슷한 핵심 메서드 집합을 정의합니다.

개인 설정 데이터 저장소 변경

ASP.NET 2.0에서 제공되는 대부분의 공급자와 마찬가지로, 기본 개인 설정 공급자는 SQL Server 백 엔드를 대상으로 하도록 구현됩니다. 구성 파일을 변경하지 않으면 기본 SqlPersonalizationProvider는 로컬 파일 기반 데이터베이스를 지원하는 SQL Server 2005 Express Edition 연결 문자열을 사용합니다. 이 연결 문자열은 다음과 같습니다.

data source=.\SQLEXPRESS; Integrated Security=SSPI; 
AttachDBFilename=|DataDirectory|aspnetdb.mdf; User Instance=true

SQL Server 2005 Express Edition 파일 기반 데이터베이스를 사용하는 이점은 사용자의 추가적인 설치 작업 없이도 즉시 만들 수 있다는 것입니다. 따라서 새 사이트를 만든 후 데이터베이스를 설치하지 않고 바로 개인 설정 기능을 사용할 수 있습니다. 사이트와 처음으로 상호 작용하면 사이트의 App_Data 디렉터리에 새 aspnetdb.mdf 파일이 만들어지며, 해당 파일은 모든 기본 공급자를 지원하는 데 필요한 테이블 및 저장 프로시저를 사용하여 초기화됩니다.

이는 확장하거나 다수의 동시 사용자를 지원할 필요가 없는 소규모 사이트에는 매우 효과적이지만, 엔터프라이즈 시스템의 경우에는 전체적으로 관리되는 전용 데이터베이스 서버에 데이터를 저장해야 합니다. 다행히도 SqlPersonalizationProvider에서 사용하는 데이터베이스를 변경하는 작업은 간단합니다. SqlPersonalizationProvider 구성은 연결 문자열을 LocalSqlServer로 초기화합니다. 즉, 구성 파일의 <connectionStrings> 섹션에서 이름이 LocalSqlServer인 항목을 찾아 관련된 연결 문자열을 사용하여 데이터베이스에 대한 연결을 엽니다. 기본적으로 이 문자열은 앞서 살펴보았던 연결 문자열, 즉 로컬 SQL Server 2005 Express Edition의 .mdf 파일에 기록되는 문자열입니다. 이 문자열을 변경하려면 먼저 LocalSqlServer 연결 문자열 컬렉션을 지운 다음 Web.congif 파일에 새 연결 문자열 값을 다시 지정합니다. 또는 컴퓨터 차원의 Machine.config 파일에서 이를 변경하여 해당 컴퓨터의 모든 사이트에 적용되도록 할 수도 있습니다. 다음은 공급자 데이터베이스가 로컬 SQL Server 2000 인스턴스를 가리키도록 변경하는 예제 Web.config 파일입니다.

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/
   V.2.0">
  <connectionStrings>
    <clear />
    <add name="LocalSqlServer" connectionString=
        "server=.;integrated security=sspi;database=aspnetdb"/>
  </connectionStrings>
  ...
</configuration>

이와 같은 변경 사항이 적용되도록 하려면 이름이 aspnetdb이며 SqlPersonalizationProvider에 필요한 테이블 및 저장 프로시저가 갖춰진 데이터베이스가 로컬 서버에 있어야 합니다. 이 데이터베이스를 만들려면 ASP.NET 2.0과 함께 제공되는 aspnet_regsql.exe라는 유틸리티를 사용합니다. 이 유틸리티를 기본 설정으로 실행하면 모든 공급자에게 필요한 테이블이 들어 있는 aspnetdb라는 데이터베이스가 로컬에 만들어집니다. 또는 기존 데이터베이스에 테이블 및 저장 프로시저를 설치할 수도 있습니다. 기존 테이블과 충돌하지 않도록 테이블 및 저장 프로시저 이름 앞에는 모두 "aspnet"이라는 접두사가 붙습니다.

ASP.NET 2.0의 모든 공급자와 마찬가지로, 이러한 간접 작업을 수행하면 포함된 페이지 또는 웹 파트를 수정하지 않아도 백 엔드 데이터 저장소를 완전하게 변경할 수 있는 매우 융통성 있는 아키텍처를 만들 수 있습니다.

고유한 개인 설정 공급자 만들기

개인 설정 공급자의 연결 문자열을 변경하는 기능을 사용하면 작업을 융통성 있게 수행할 수 있지만, SqlPersonalizationProvider는 System.Data.Sql.Client 네임스페이스를 사용하여 해당 데이터 검색을 수행합니다. 즉, 이 작업은 SqlServer 데이터베이스로 제한됩니다. 개인 설정을 다른 데이터베이스 또는 완전히 다른 데이터 저장소에 저장해야 하는 경우에는 다음 단계를 수행하여 직접 사용자 지정 개인 설정 공급자를 빌드해야 합니다. 다행히도 힘든 작업은 대부분 완료되었으므로 이를 간편하게 활용할 수 있습니다. 개인 설정 데이터를 다른 데이터 저장소에 기록하는 작업의 예로, 이 기사에 나오는 샘플 포털 사이트에서는 응용 프로그램의 App_Data 디렉터리에 있는 로컬 이진 파일에 모든 개인 설정 및 사용자 지정 데이터를 보관하는 FileBasedPersonalizationProvider라는 사용자 지정 개인 설정 공급자를 완전하게 구현합니다. 이진 파일 이름은 각 사용자 및 경로에 대해 고유하게 생성되며 일반 사용자 설정에 대해 고유한 경로마다 파일이 하나씩 있습니다.

사용자 지정 개인 설정 공급자를 빌드하려면 먼저 PersonalizationProvider 기본 클래스에서 상속을 받는 새 클래스를 만든 다음 기본 클래스에서 상속된 모든 추상 메서드를 다시 정의해야 합니다. 그림 17에 나와 있는 클래스 선언을 통해 이 작업을 수행하는 방법을 확인할 수 있습니다.

개인 설정 공급자가 작동하도록 하기 위해서는 두 가지 중요한 메서드, 즉 LoadPersonalizationBlobs 및 SavePersonalizationBlob만 구현하면 됩니다. 이 두 메서드는 이진 serialization 및 개인 설정 데이터를 나타내며, 개인 설정 인프라에 의해 호출되어 페이지 로드 시 데이터를 검색하고 웹 파트가 있는 페이지에서 데이터가 편집, 카탈로그 또는 디자인 보기에서 변경될 때 보통 특정 사용자를 대신하여 데이터를 다시 씁니다.

다운로드한 샘플 코드의 SavePersonalizationBlob 구현은 전달된 userName 및 경로를 기반으로 만들어진 고유한 이름의 파일에 dataBlob 매개 변수를 기록합니다. 마찬가지로 LoadPersonalizationBlobs 구현은 동일한 명명 스키마를 사용하여 파일을 검색해 사용자 데이터 blob 또는 공유 데이터 blob를 반환합니다. 이러한 두 메서드는 들어오는 userName 매개 변수가 null인 경우 기본적으로 공유 데이터를 저장 또는 로드하며, 그렇지 않은 경우에는 사용자 데이터를 저장 또는 로드합니다. 그림 18은 샘플 FileBasedPersonalizationProvider에서의 이 두 메서드 구현과 함께, 사용자 이름 및 경로 정보를 기반으로 고유한 파일 이름을 생성하기 위한 도우미 메서드 쌍을 보여줍니다.

공급자를 완전히 구현하고 나면 개인 설정 구성 섹션의 공급자 섹션을 사용하여 해당 공급자를 등록된 개인 설정 공급자로 추가할 수 있습니다. 실제로 공급자를 사용하려면 Web.config 파일에서 이를 개인 설정에 대한 기본 공급자로 지정해야 합니다. 다음은 사용자 지정 파일 기반 공급자를 응용 프로그램의 기본 공급자로 지정하는 예제입니다.

<webParts>
  <personalization defaultProvider="FileBasedPersonalizationProvider">
    <providers>
      <add name="FileBasedPersonalizationProvider"
           type="Wingtip.Providers.FileBasedPersonalizationProvider" />
    </providers>
  </personalization>
</webParts>

사이트를 다시 실행하면 모든 개인 설정 데이터가 로컬 이진 파일에 저장되어 있습니다. 이 기사의 샘플이 가장 확장이 용이한 솔루션이라고 할 수는 없지만, 이 샘플을 통해 원하는 백 엔드에서 사용자의 고유한 개인 설정 공급자를 구현하는 방법에 대해 파악할 수 있습니다. 그림 19에서는 전체 웹 파트 인프라에 연결된 새로운 공급자를 보여줍니다.

그림 19. FileBasedPersonalizationProvider 사용

추가 정보

지금까지 ASP.NET 2.0 및 여기에 포함된 새로운 웹 파트 컨트롤 집합을 사용하여 사용자 지정 및 개인 설정을 지원하는 유용한 포털 응용 프로그램을 비교적 쉽게 만드는 방법을 알아보았습니다. 이 인프라의 가장 중요한 기능은 연결성일 것입니다. 공급자 인프라를 사용하면 특정 serialization 구현 및 데이터 저장소에 제한되는 대신 사용자 사이트에 적합한 백 엔드 데이터 저장소에 개인 설정 데이터를 비교적 쉽게 쓸 수 있습니다. 이제 ASP.NET 2.0 웹 파트를 사용하여 사용자 지정 가능한 사이트를 만들어 보십시오.

이 기사가 유용했다면 ASP.NET 2.0 포털 응용 프로그램에서 웹 파트를 사용한 빌드에 관한 더욱 자세한 정보를 살펴보실 수 있습니다. MSDN Magazine 웹 사이트에서 함께 제공하는 샘플을 꼭 다운로드하시기 바랍니다. ASP.NET 2.0 QuickStart 자습서 (영문)에는 작업에 사용할 수 있는 샘플이 다수 마련되어 있습니다. 또한 ASP.NET 2.0의 웹 파트 사용과 관련된 여러 가지 흥미로운 예제를 확인할 수 있는 Fredrik Normen의 블로그 (영문)도 방문해 보시기 바랍니다