사용자 지정 데이터 바인딩

사용자 지정 데이터 바인딩

Michael Weinhardt
http://www.mikedub.net/

요약: Michael Weinhardt가 코드를 사용하지 않고도 사용자 지정 형식을 완전한 목록 데이터 원본으로 만들 수 있는 여러 가지 새로운 디자이너 향상 기능 및 추가 기능에 대해 설명합니다. 또한 베타 2에서 향후 제공될 예정인 향상된 기능에 대해서도 살펴봅니다.

winforms11162004_sample.msi 파일을 다운로드하십시오.

소개

최근에 대만 타이베이에 사는 친구를 방문할 기회가 있었습니다. 여행을 무척 좋아하는 제게는 좋은 경험이었습니다. 특히 저는 조금씩이나마 현지 언어를 배우는 것을 좋아합니다. 그러는 것이 현지 문화를 존중하는 의미도 되고 여행을 더욱 흥미롭게 만들기 때문입니다. 타이베이에서는 대만 사람에게 맞게 수정된 현대적인 표준 중국어를 사용합니다. 저는 언어 전문가가 아니므로 혹시 잘못된 곳이 있더라도 너그럽게 이해해 주시기 바랍니다(Visual Studio Tools for Office 2005 릴리스는 현재 한국어로 제공되지 않습니다. 한국어 버전은 이후 제공될 예정입니다).

대부분의 사람처럼 저도 숫자부터 배우기 시작했습니다. 속으로 영어를 중국어로 번역하지 않아도 될 정도로 숫자를 외우려고 노력했습니다. 그러기 위해 재미있게 외울 수 있는 방법을 찾아보았습니다. 그 방법 중 하나가 횡단 보도에서 기다리는 것이었습니다. 타이베이에 있는 대부분의 신호등에는 일반적인 녹색과 빨간색의 사람 모양이 있을 뿐 아니라, 신호가 바뀔 때까지 남은 시간을 초 단위로 보여 주는 숫자도 표시됩니다. 그 숫자가 줄어드는 속도에 맞춰서 숫자를 중국어로 말하는 것이 특히 어려웠습니다. 처음에는 정말 형편없었죠.

그림 1. 대만의 횡단 보도 시간 표시 숫자

이 횡단 보도 신호등 게임에서 영감을 얻어서 여러 가지 단어, 숫자 및 구를 사용하는 비슷한 종류의 컴퓨터 게임을 제공하는 Windows Forms 응용 프로그램을 만들어 보기로 했습니다. 기본적인 개념은 응용 프로그램에서 단어, 숫자, 구 등이 순서 없이 무작위로 깜박이며 표시될 때 이를 중국어로 번역하여 말하는 것입니다.

데이터 캡처

첫 번째 단계는 각 단어, 숫자 또는 구에 대해 수집해야 하는 정보를 결정하는 것입니다. 결국 영어 표현(번역할 내용), '병음(Pinyin)'이라고 하는 중국어의 로마자 표기 버전(번역 결과), 중국어 문자 이미지(중국어로 쓰는 방법), 발음(중국어로 읽는 방법) 정보를 수집하기로 결정했습니다.

참고병음(Pinyin)은 로마자 알파벳을 사용하여 중국어를 쓰는 방법입니다. 저처럼 언어 능력이 약한 사람에게는 매우 유용합니다. 자세한 내용은 http://en.wikipedia.org/wiki/Pinyin을 참고하십시오.

이를 염두에 두고 원하는 게임 데이터를 캡처하기 위한 UI를 빌드했습니다. 어디서나 쉽게 이 게임을 즐길 수 있도록 데이터베이스에 이 정보를 보관하지 않았습니다. 대신 사용자 지정 Word 형식을 사용하여 정보를 캡처하기로 했습니다. 이 방법은 특정 시점에서 .NET Framework의 serialization 지원을 활용합니다.

[Serializable]
public class Word {

// 생성자
public Word(string english, string pinyin,
Image character, byte[] pronunciation);

// 속성
public string English { get; set; }
public string Pinyin { get; set; }
public Image Character { get; set; }
public byte[] Pronunciation { get; set; }
}(참고: 프로그래머 코멘트는 샘플 프로그램 파일에는 영문으로 제공되며 기사에는 설명을 위해 번역문으로 제공됩니다.)

데이터 표시

여러 개의 단어, 숫자 및 구가 필요하므로 0개 또는 그 이상의 Word 데이터 항목으로 구성된 목록 데이터 원본이 필요합니다. 그리고 Words 목록을 표시하는 데 가장 적합한 UI 스타일을 결정해야 합니다. 두 가지 일반적인 UI 패턴 표시 목록 데이터 원본이 있습니다.

• 자세히 보기 UI
• 목록 보기 UI

자세히 보기 UI는 일반적으로 목록 데이터 항목을 한 번에 하나씩 표시하며 각 데이터 항목의 공개 속성이 자체 컨트롤에 연결되어 있습니다. 한 번에 하나의 데이터 항목만 표시되므로 자세히 보기 UI는 보통 목록의 앞뒤로 이동할 수 있는 탐색 명령을 제공합니다. 이러한 명령은 주로 메뉴 모음을 통해 또는 VCR 스타일 도구 모음으로 UI에 추가됩니다. 그림 2에 자세히 보기 UI가 나와 있습니다.

그림 2. 자세히 보기 UI

목록 보기 UI는 이름 그대로 컨트롤의 목록이나 데이터 표 스타일을 사용하여 여러 데이터 항목을 표시합니다. 즉, 그림 3에 나온 폼과 같습니다.

그림 3. 목록 보기 UI

자세히 보기 UI는 데이터 항목 속성이 너무 많아서 목록에 제대로 표시하기 어려운 상황에서 특별한 경우에 가끔씩만 찾아볼 때 매우 적합합니다. 또한 목록 스타일 컨트롤에서 일반적으로 가능한 것보다 UI를 더 융통성 있게 사용하고 제어해야 하는 경우에도 유용합니다. 반면에 목록 보기 UI는 데이터 입력에 적합합니다. 특히 중요한 데이터 행을 한 번에 순서대로 입력하는 경우에 유용합니다. 저는 게임 데이터를 대량으로 입력할 생각이므로 목록 보기 UI가 더 적절할 듯합니다.

따라서 UI를 빌드하려면 단일 Word 형식을 목록 데이터 원본으로 변환해야 합니다. 이 목록 데이터 원본은 적절한 목록이나 데이터 표 스타일 컨트롤을 통해 표시됩니다. 이러한 상황에는 DataGridView 컨트롤을 사용하는 것이 좋을 것 같습니다. 그런 다음에는 DataGridView와 목록 데이터 원본 간에 모든 편집 내용이 동기화되도록 해야 합니다. 많은 양의 데이터를 사용할 예정이므로 쉽게 탐색할 수 있도록 하는 VCR 스타일 컨트롤이 필요합니다. 이러한 컨트롤은 어느 쪽에서든 탐색 작업이 수행되면 컨트롤과 DataGridView 간에 통화(현재 목록 위치)가 동기화되도록 합니다.

데이터 바인딩

이러한 모든 요구 사항을 지원하도록 디자인된 기본적인 메커니즘이 데이터 바인딩입니다. 이 메커니즘은 데이터 원본을 UI 컨트롤에 연결(바인딩)합니다. 데이터 원본이 바인딩된 후에 데이터 바인딩이 수행하는 주요 작업은 편집 및 탐색 동기화를 자동으로 관리하는 것입니다.

Windows Forms 1.x에서는 목록 데이터 원본을 바인딩하려면 적어도 System.ComponentModel.IList를 구현해야 합니다. 즉, 개발자가 강력한 형식의 IList 구현을 직접 생성하거나 최소한 .NET Framework의 미리 구성된 IList 구현(예: 간단한 형식 배열 및 ArrayList) 중 하나를 활용해야 합니다. 빌드된 후에는 바인딩이 이루어지도록 목록 컨트롤의 DataSource 속성이 IList 구현으로 설정되어야 합니다. 데이터 원본이 형식이 지정된 데이터 집합(.xsd)인 경우에는 DataSet 구성 요소를 폼에 추가하여 형식이 지정된 데이터 집합을 폼의 컨트롤에 바인딩된 데이터에 표시함으로써 선언적으로 바인딩할 수 있습니다. 실제 바인딩은 그림 4와 같이 DataSource 및 DataMember 속성을 적절히 설정함으로써 수행됩니다.

그림 4. Windows Forms 2.0 이전의 선언적 데이터 바인딩

또는 프로그래밍 방식을 택할 수도 있습니다.

// DataGrid를 목록 데이터 원본에 바인딩합니다.
this.northwindDataGrid.DataMember = "직원";
this.northwindDataGrid.DataSource = this.northwind;

그러나 불행히도 이러한 뛰어난 기능은 사용자 지정 형식을 기반으로 하는 목록 데이터 원본에 대해서는 제대로 작동하지 않습니다. 우선 이러한 데이터 원본은 Windows 1.x Forms 디자이너에 표시되지 않습니다. 둘째로, DataSource 속성을 사용하여 IList 구현을 목록 컨트롤에 바인딩할 수는 있지만 디자인 타임에 열을 자동으로 검색하고 만드는 DataGrid 지원은 사용할 수 없습니다. 뿐만 아니라 목록 데이터 원본이 기본적인 편집 및 탐색을 지원하도록 하려면 다른 여러 가지 인터페이스를 구현해야 할 수도 있습니다.

따라서 Windows Forms 1.x에서 사용자 지정 형식을 만든 후에는 이를 유용한 목록 데이터 원본으로 변환해야 합니다. Windows Forms 2.0을 사용하고 있다면 마우스를 몇 번 클릭하고 잠깐 동안만 작업하면 됩니다.

단계적 작업 수행

사용자 지정 형식을 가져와서 완전한 목록 데이터 원본으로 변환하고 DataGridView에 바인딩한 다음 VCR 스타일 탐색을 추가하려면 먼저 프로젝트가 사용자 지정 형식을 데이터 원본으로 인식하도록 구성해야 합니다.

프로젝트 데이터 원본 추가

사용자 지정 형식은 두 가지 방법 중 하나를 통해 데이터 원본으로 등록할 수 있습니다. 첫 번째는 Visual Studio .NET 2005 | Data(데이터) | Add New Data Source...(새 데이터 원본 추가...)를 선택하고 지시를 따르는 방법이고, 두 번째는 Data Sources(데이터 원본) 도구 창(Visual Studio .NET 2005 | Data(데이터) | Show Data Sources(데이터 원본 표시))을 열고, 그림 5와 같이 데이터 원본이 없으면 Add New Data Source...(새 데이터 원본 추가...) 링크를 클릭하는 방법입니다.

그림 5. 비어 있는 Data Sources(데이터 원본) 도구 창

Visual Studio .NET 2005 베타 1에서 프로젝트에 이미 데이터 원본이 있는 경우 Data Sources(데이터 원본) 도구 창의 상황에 맞는 메뉴를 표시하여 Add New Data Source...(새 데이터 원본 추가...)를 선택하거나 가장 왼쪽에 있는 도구 모음 아이콘을 클릭해야 합니다. 어떤 방법으로 새 데이터 원본을 선택하든 그림 6과 같이 Data Source Configuration Wizard(데이터 원본 구성 마법사)를 시작하고 먼저 데이터 원본 형식부터 지정합니다.

그림 6. 데이터 원본 형식 선택 대화 상자

그림 6에서 볼 수 있듯이 Microsoft SQL Server와 같은 데이터베이스 서버, Microsoft Access .mdb와 같은 로컬 데이터베이스 파일, Word 등의 사용자 지정 개체 또는 DataSets와 같이 적절한 개체를 반환하는 웹 메서드가 있는 웹 서비스, 그리고 개체 등 4가지 데이터 원본 형식 중에서 선택할 수 있습니다. 여기서 "개체"란 말 그대로 개체(실제로는 "형식")를 의미합니다. 마법사의 다음 단계에서 형식을 선택할 수 있습니다. 그림 7은 사용자 지정 Word 형식을 선택한 경우입니다.

그림 7. Word 개체 선택

여기서는 Business Object(비즈니스 개체)가 사용되기는 하지만 그림 7에 나온 것처럼 프로젝트의 응용 프로그램 설정 등 비즈니스 개체가 아닌 개체도 등록할 수 있습니다. 물론 우리는 Word를 선택하고 Next(다음) 단추를 클릭하여 그림 8과 같이 원하는 데이터 원본이 Data Sources(데이터 원본) 도구 창에 추가되도록 할 것입니다.

그림 8. 선택한 개체 데이터 원본이 있는 Data Sources(데이터 원본) 도구 창

DataConnector

다음 단계가 가장 중요합니다. 데이터 원본을 단일 형식에서 데이터 바인딩된 목록 컨트롤이 바인딩될 수 있는 적절한 목록 데이터 원본으로 변환해야 합니다. 이 작업에는 새 DataConnector 구성 요소를 사용합니다. 그림 9와 같이 Toolbox에서 폼으로 끌어 놓은 다음 DataSource 속성을 적절한 목록 데이터 원본으로 설정하면 됩니다.

그림 9. DataConnector 구성 요소 추가 및 구성

그러면 Windows Forms 2.0 디자이너가 InitializeComponent에 다음 코드를 생성합니다.

private void InitializeComponent() {
...
//
// wordDataConnector
//
...
this.wordDataConnector.DataSource =
typeof(winforms11162004_DataBinding.Word);
...
}

이 코드 줄이 실행되면 DataConnector가 데이터 원본을 검사하여 IList 구현 여부를 확인합니다. 구현하지 않는 경우 DataConnector는 내부 IList 구현을 만들어 사용자 지정 형식을 보관합니다. 구체적으로는 이 기사의 뒷부분에서 설명할 일반 BindingList 구현을 만듭니다. DataConnector가 IList 구현에 바인딩되어 있는 경우에는 이 단계가 필요하지 않습니다. 하지만 수행해도 결과는 마찬가지입니다. 결국 DataConnector는 사용자 지정 형식을 소비하며, 대신 해당 형식을 자체 IList 구현을 사용하여 올바른 목록 데이터 원본으로 데이터 바인딩된 컨트롤에 표현한다는 것입니다. 간단한 눈속임인 셈입니다.

DataGridView를 대신 바인딩

이제 DataGridView를 폼으로 끌어 해당 DataSource 속성을 설정할 수 있습니다. 짐작하셨겠지만 이 속성은 DataConnector 자체로 설정되므로 목록 데이터 원본의 역할을 대신 수행합니다. 이 내용은 그림 10에 설명되어 있습니다.

그림 10. DataConnector에 바인딩된 DataGridView

생성되는 InitializeComponent 코드는 다음과 같습니다.

private void InitializeComponent() {
...
//
// wordDataGridView
//
...
this.wordDataGridView.DataSource = this.wordDataConnector;
...
}

DataConnector는 데이터 바인딩 가능 컨트롤이 있는 영역에 완전한 목록 데이터 원본을 해당 데이터 항목 설명자 정보와 함께 제공하므로, DataGridView와 같은 컨트롤은 이 정보를 검사 및 활용하여 적합한 열을 자동으로 생성할 수 있습니다. 이 기능도 위의 그림 10에 나와 있습니다.

DataNavigator

마지막으로 구현할 기능은 VCR 스타일 탐색입니다. 다행히도 DataConnector는 통화 관리자 역할도 하므로 여기서도 유용하게 활용할 수 있습니다. 즉, DataConnector는 현재 데이터 항목을 추적하며 목록 데이터 원본을 프로그래밍 방식으로 탐색하기 위해 코딩할 때 사용할 수 있는 메서드, 속성 및 이벤트를 구현합니다.

public class DataConnector : ... {
...
// 속성
public int Position { get; set; }
public object Current { get; }
...
// 메서드
public void MoveFirst();
public void MoveLast();
public void MoveNext();
public void MovePrevious();
...
// 이벤트
public event EventHandler CurrentItemChanged;
public event EventHandler PositionChanged;
public event AddingNewEventHandler AddingNew;
}

이러한 멤버를 사용하는 기본 탐색은 다음과 같습니다.

private void firstToolStripMenuItem_Click(object sender, EventArgs e) {
this.wordDataConnector.MoveFirst();
}
private void prevToolStripMenuItem_Click(object sender, EventArgs e) {
this.wordDataConnector.MovePrevious();
}
private void nextToolStripMenuItem_Click(object sender, EventArgs e) {
this.wordDataConnector.MoveNext();
}
private void lastToolStripMenuItem_Click(object sender, EventArgs e) {
this.wordDataConnector.MoveLast();
}

이 메서드를 호출하면 DataConnector가 원하는 목록 데이터 항목으로 이동하며 UI가 적절하게 업데이트되도록 탐색이 DataConnector에 바인딩된 컨트롤과 동기화됩니다.

반면에 DataNavigator를 폼으로 끌어 놓고 DataSource 속성을 다시 한 번 사용하여 DataConnector에 바인딩하는 것이 더 쉽다고 판단할 수도 있습니다. 결과는 동일하기 때문입니다. 뿐만 아니라 추가 및 삭제 기능을 자유롭게 사용할 수 있습니다. DataNavigator는 저장 및 로드 같은 광범위한 목록 데이터 원본 관련 작업을 제공하도록 확장할 수 있는 특수 도구 스트립 컨트롤입니다.

DataNavigator를 추가하면 완성된 UI는 그림 11과 같습니다.

그림 11. 코드가 없는 완성된 UI

지금까지 사용자 지정 Word 형식(목록이 아님)을 만들었고, 하나의 마법사를 사용했고, DataConnector, DataGridView 및 DataNavigator를 각각 하나씩 추가했으며, 세 가지 속성을 설정했습니다. 전반적으로 어렵지 않은 작업이었을 것입니다.

개발자를 위한 자동 기능

그러나 굳이 DataConnector 및 DataNavigator 구성 요소를 끌어서 놓고 구성하는 데 시간을 소비하지 않아도 됩니다. 그림 12와 같이 사용자 지정 데이터 원본을 폼에 끌어다 놓으면 되는 훨씬 쉬운 방법이 있기 때문입니다.

그림 12. 프로젝트 데이터 원본을 폼에 끌어서 놓기

이 기술을 사용하면 지금까지 UI를 빌드하기 위해 수행한 작업이 모두 Windows Forms 2.0 디자이너에서 자동으로 수행됩니다. 혹시 작업이 수행되는 동안 커피를 마실 생각을 했다면 커피를 마시기는커녕 채 끓이지도 못할 시간 내에 모든 작업이 완료됩니다. 또한 작업을 위해 생성되는 코드는 기본적으로 개발자가 직접 작성해야 하는 코드와 동일합니다.

참고이 기사를 작성할 당시에는 이 메서드를 사용한 결과 필요한 4개의 열 중에 3개만 생성되었습니다. 베타 2에서는 아니더라도, 정식 Windows Forms 2.0 릴리스에서는 이 기사에서 설명한 두 가지 방법을 사용하면 똑같은 결과를 얻을 수 있을 것이라고 기대합니다.

Data Sources(데이터 원본) 도구 창을 사용하면 좀 더 편리하게 작업을 수행할 수 있습니다. 예를 들어, 데이터 원본을 폼으로 끌어서 놓을 경우 목록(DataGridView) 또는 자세히 스타일 UI가 생성되도록 구성할 수 있습니다. 또한 각 항목 속성이 어떠한 종류의 컨트롤로 생성되어야 하는지를 지정할 수 있습니다. 그림 13은 사용 중인 이 두 항목을 보여 줍니다.

그림 13. UI 생성 지시

마지막으로 그림 13의 메뉴에서 Customize...(사용자 지정...)를 선택하면 기본 선택 목록에 추가하거나 목록에서 제거할 수 있습니다.

최종 조정 단계

물론 디자이너가 만들 수 있는 것은 여기까지가 한계입니다. 예를 들어, 디자이너는 개발자가 원하는 열 순서를 알 수 없습니다. 또한 바이트 배열은 수많은 데이터 형식으로 되어 있기 때문에, 디자이너는 나름대로 최선을 다해 Pronunciation 바이트 배열 속성을 이미지로 해석했지만 실제로 이 속성은 소리가 들어가야 하는 곳입니다. 이 중 첫 번째 문제를 해결하려면 DataGridView 열 편집기를 사용하여 열 순서를 업데이트하면 됩니다. 두 번째 문제를 해결하기 위해서는 각 셀을 마우스로 한 번 클릭할 때 발음을 들려 주는 사용자 지정 DataGridView 발음 열/셀 구현을 만들어야 합니다. 이 구현에 대한 내용은 이 기사에서 다루는 범위를 벗어나므로, Wonders of Windows Forms의 2004년 2월 기사에서 자세한 내용을 확인하십시오. 이 기사는 알파 버전을 기초로 해서 작성된 것이라서 베타 1에서 몇 가지 변경된 점이 있지만 개념 자체는 동일합니다.

마지막으로 비트맵 및 wav 파일을 Character 및 Pronunciation 열에 쉽게 추가할 수 있도록 두 열에 모두 끌어서 놓기 지원 기능을 추가했습니다. 구현 정보를 자세히 살펴보려면 코드 샘플을 확인해 보십시오.

이렇게 약간 수정한 최종 폼은 그림 3에서 본 샘플과 같습니다.

Windows Forms 2.0 베타 2의 향상된 기능

이 기사에서 언급한 기술은 Windows Forms 2.0 베타 1을 기준으로 합니다. 베타 2에서는 당연히 변경 사항이 있었겠죠? 고맙게도 Microsoft의 Joe Stegman과 Steve Lasker가 귀중한 시간을 할애하여 베타 2의 데이터 바인딩에서 활용 가능한 업데이트 및 향상된 기능을 일일이 설명해 주었습니다.

먼저, 몇 가지 이름이 바뀝니다. 대표적으로는 DataConnector가 BindingSource로, 그리고 DataNavigator가 BindingNavigator로 바뀝니다. 개인적으로는 새 이름이 구성 요소의 실제 역할을 더 정확하게 표현한다고 생각합니다. 즉, 공개하는 데이터 원본이 아니라 바인딩 원본을 나타내고 이를 사용하여 작업하는 것입니다.

둘째로, Data Sources(데이터 원본) 도구 창과 Data Source Configuration Wizard(데이터 원본 구성 마법사)가 간편해졌습니다. 업데이트된 Data Sources(데이터 원본) 도구 창은 그림 14와 같이 좀 더 자세한 설명을 제공합니다.

그림 14. 베타 2 Data Sources(데이터 원본) 창

Data Source Configuration Wizard(데이터 원본 구성 마법사)도 마찬가지입니다. 데이터 원본 선택 단계의 옵션이 단순화되었고 각 옵션에서는 수행할 수 있는 작업에 대한 자세한 정보가 제공됩니다. 그림 15는 개체 데이터 원본을 선택하는 경우를 보여 줍니다.

그림 15. 보다 단순해지고 자세한 설명을 제공하는 데이터 원본 선택

마법사의 다음 단계인 바인딩할 형식을 선택하는 대화 상자도 향상되어 그림 16과 같이 세 부분으로 구분됩니다.

그림 16. 더 많은 기능이 추가된 형식 바인딩 선택

"Microsoft." 및 "System." 어셈블리를 표시하거나 숨길 수 있습니다. 형식과 연결된 XML 주석은 설명 텍스트로 표시되며 그림 7과 같이 목록에서 네임스페이스 뒤에 오는 밑줄은 이제 마침표로 올바르게 표시됩니다.

마지막으로 데이터 원본을 폼에 DataGridView로 끌어 오면 제대로 지정된 DataGridView 및 DataGridViewColumn 이름이 생성됩니다. 현재는 단순히 첫 단어는 소문자이고 다른 모든 단어의 경계는 대문자이며 밑줄이 없는 형식인 DataGridView 열 형식 이름과 숫자(예: dataGridViewTextBoxColumn1)로 이름이 지정됩니다. 베타 2 이름은 데이터 원본 필드 이름과 DataGridView 열 형식 이름이 결합된 형태가 될 것입니다.

기술은 바뀌더라도 이 기사에서 설명한 개념 자체는 바뀌지 않습니다. 그러므로 가능하면 베타 1부터 익히기 시작하는 것이 좋습니다.

정리

아직 저는 응용 프로그램을 완성하지는 못했지만, 수많은 중국어 데이터를 입력하다 보니 중국어 실력은 확실히 나아진 것 같습니다. 중국어로 BBQ 버거 10개를 제대로 주문했으니 말입니다. 또한 단일 사용자 지정 형식을 올바른 목록 데이터 원본으로 변환하는 두 가지 기술을 실습해 보는 좋은 기회가 되었습니다. DataConnector라는 새로운 데이터 바인딩 기능을 주로 사용해서 말이죠. DataConnectors는 바인딩된 컨트롤과 목록 데이터 원본 사이에서 편집 내용이 동기화되도록 하고 VCR 스타일 DataNavigator를 통해 탐색도 동기화되도록 합니다. 개발에 필요한 전체 작업은 많지 않습니다. 특히 Windows Forms 1.x와 비교하면 대폭 줄어듭니다.

그러나 샘플을 살펴보면 정렬, 검색 및 필터링을 비롯한 특정 기능이 빠져 있는 것을 확인할 수 있습니다. 이러한 기능도 폼에서 구현할 수는 있지만 재사용 측면에서 보면 목록 데이터 원본 자체에 구현하는 것이 더 효율적입니다. 그래야 데이터 바인딩된 컨트롤이 이러한 기능을 활용할 수 있기 때문입니다. 다음 기사에서는 IBindingList를 구현하여 정렬 및 검색 기능을 추가하는 방법을 살펴봅니다. 이 작업은 새로운 BindingList<T> 일반 형식에서 파생함으로써 쉽게 수행할 수 있습니다. 또한 IBindingListView를 구현하여 고급 정렬 및 필터링 기능을 추가하는 방법도 알아봅니다. 마지막으로 응용 프로그램의 게임 데이터 관리 부분을 완성하기 위해 .NET Framework의 serialization 지원을 통한 지속성을 추가하겠습니다.

감사의 말

저를 따뜻하게 환영해 주셨던 타이베이 분들께 감사의 말을 전합니다. 특히 제가 대만 여행을 할 수 있도록 해 주신 분께 감사합니다. 마지막으로 이 기사를 위해 시간과 노력을 투자해 준 Microsoft의 Steve Lasker와 Joe Stegman에게 특별한 감사의 말을 전합니다.

참고 자료

Object Binding, Steve Lasker, CoDe Magazine, 2004년 9월/10월