WPF를 생각한다.

프로그래밍 2010.08.11 00:46 Posted by 아일레프

고작 2년 남짓 경력을 가지고, 이제야 눈을 가리고 있던 장막이 조금 걷히는 나로써 이 커다란 코끼리를 얘기 한다는 것이 우습지만. 감히 WPF에 대한 이야기를 하려 한다. 어쩌면 길지도 모르는 이 글을 읽기 전에 전에 알아야 할 사항이 있다. 난 약 2년 동안 .NET 프레임워크 위에서 WPF만 가지고 놀았다. 그리하여 WPF가 이제 내게는 둘도 없는 친한 친구이다. 따라서 이에 대한 이야기가 아무래도 중립적일 수 없다. 스스로 아무리 객관적으로 판단하려고 애를 써도 어느 정도 애정이 들어가기 때문이다. 따라서 이 글 내에서 WPF의 긍정적인 부분은 어느 정도 과장되고, 부정적인 부분은 축소될 수 밖에 없는 운명에 있다는 것을 밝힌다. 그리고 그 부분을 고려해 WPF에 대해 판단하는 것은 이 글을 읽고 있는 그대의 몫이다.

 

 

 

View의 것은 XAML에게, 논리의 것은 .cs에게

 

응집력. 프로그래머들이 클래스를 설계하고 리팩토링할 때 반드시 고려해야 하는 것 중 하나다. 이 원칙에 의해 UI 어플리케이션에 포함되는 클래스를 설계할 때 성숙한 개발자라면 반드시 View와 논리를 분리를 고려해 클래스를 설계할 것이다설계를 마친 후 그 클래스를 구현할 시점에 느끼게 되지만논리를 구성하고 만드는 일은 참 재미있는 일이다.(나에게는 그러했다.) 그러나, 단순한 노가다 처럼 느껴지는 View를 만드는 작업은 너무 귀찮고 그 귀찮음이란 너무 고통스럽다. UI Application의 역사를 보면 이와 같은 생각을 가진 지독히 게으른 개발자들의 고뇌를 읽을 수 있다. 그들이 고안한 다양한 시도들에 대해서는 여러분도 익히 알고 있을 것이다. 그리고 감히 말하건데, 그 시도들은 WPF에서 화려한 꽃을 피운 것으로 보인다. View는 이제 온전히 XAML의 것이 되었다. 어느 정도 숙달된 WPF개발자라면 더 이상 .cs코드에 new Button(); 등으로 UIElement요소를 직접 생성하지 않아도 됨을 알 수 있을 것이다.(만약 현재 당신의 WPF코드 내에 new 키워드로 UIElement를 생성하고 있다면 부지런히 다른 방법을 고려 해봐야 한다.) 

이렇게 View가 온전히 XAML의 것이 되었다는 것은 무엇을 의미하는가? 바로 디자이너와 개발자의 온전한 분업이 가능해졌다는 것을 의미한다.('가능'이란 단어를 택했다는 것에 주의하기 바란다.) 고로 View의 것은 디자이너에게, 논리의 것은 개발자에게.

 

하지만, 문제는 남아있다. View의 것이 완전히 디자이너의 영역에 도달하려면 훌륭한 XAML툴이 필요하다이제 우리에게 주어진 것이 오직 Blend라는 프로그램뿐이라는 비극적인 현실이 기다리고 있다디자이너들에게 이 Blend만을 사용해 멀쩡한 View가 태어나기를 바라는 것은 터무니 없는 욕심이다. 이 툴이 얼마나 가혹하냐면, 개발자도 알기 어려운 에러메시지를 뿌리며 빌드가 되지 않는 것은 흔히 벌어지는 일이며, 배 깔고 발 뻗고 죽어버리는 일도 허다하다참으로 이 Blend란 툴은 애물단지이다.


내가 디자이너가 아니기에 확신할 수는 없지만, 개발자가 논리에 집착하듯이 디자이너는 아름다운 디자인에 자신의 에너지를 바친다. 그런데 그 디자이너는 틈만나면 죽는 이 Blend프로그램 때문에 알 수 없는 에러메시지를 봐야 하고, 그 때 마다 미안한 마음을 드러내며 개발자에게 Blend를 살려달라고 긴급요청을 해야 한다. 더 큰 문제는 고객의 요구가 이 Blend로 구현할 수 있는 XAML의 영역을 넘어서기에, 고객의 그 어마어마한 창의력을 현실에 옮기기 위해서, 혹은 디자이너의 머리 속에 있는 그 이상을 현실로 옮기기 위해서어쩔 수 없이 디자이너가 어느 정도 XAML을 이해 해야 하는 처지에 몰린다는 것이다. 아름다움의 세계에 머물고 싶은 디자이너들에게 이 요구는 너무 잔인하다. 때문에 View를 구성하기 위해서는 WPF개발자 한 명과 디자이너 한 명이 필요하다. 혹은 최소한 WPF XAML을 이해하고 있는 디자이너 한 명이 필요하다. 하지만 WPF의 XAML을 읽을 수 있는 디자이너는 소수이다.(귀동냥으로 들은 사실) 이 즈음에 우리 회사에 있는 두 명의 디자이너에게 감사하다는 말을 전하고 싶다. 이 분들은 XAML을 이해한 후 개발자에게 적절한 요구를 할 뿐 아니라 때에 따라서 디자이너에게는 너무 멀리 있는 Visual Studio 프로그램을 손수 연 후 .cs 코드를 직접 만지는 수고를 감내하기도 한다. 신이여 그녀들에게 축복을!

 

WPF 기술은 어느 정도 완성되었다. 그렇지만 Blend는 그 기술을 따라잡기에 너무 벅차며, 그 기술을 따라잡고자 하는 노력이 부족하다는 것에 내 분노의 뿌리가 있다.(Blend4는 WPF4 지원한다고 하면서 x:TypeArguments, x:Reference 같은 XAML 2009문법을 이해하지 못한다.)  때문에 개발자와 디자이너와의 완전한 분업이란 Blend만 존재하는  현실에서 환상이다.

  

 

View의 것은 View에게, 논리의 것은 ViewModel에게. Binding. 그 놀라운 힘.

 

언젠가 문득 UserControl .cs클래스 내에 this.DataContext= this; 또는 UserControl XAML내에 DataContext=”{Binding RelativeSource={RelativeSource Self}” 란 코드를 넣고 싶다고 느낀다면, 그대는 이미 MVVM패턴을 어느 정도 하고 있는 것이다..

 

Binding 바로 이 엄청난 녀석으로 인해 우리는 비로서 논리의 것과 View를 느슨히 연결 시킬 수 있게 되었다. 그리고 이것으로 인해 UI의 특정 동작을 일으키는 지우고 싶은 수많은 코드들을 저 세상으로 보낼 수 있게 되었다.(ex: textBlock1.Text=”dfsdf”) 이것은 View관리 코드(ViewModel)에서 특정 UIElement reference하는 코드가 더 이상 보이지 않게 됨을 의미한다. 이전에 View관리 코드와 View사이의 통신이 Event로 강하게 연결되어 있었다면 이제 Binding으로 느슨히 연결되어 응집력 있는 클래스의 설계와 구현이 가능해졌기 때문이다. 그 뿐 아니라 이것은 ViewModel– View관리 논리- 을 별도로 테스트 할 수 있음을 의미하기도 한다. 진부한 문장이겠지만 적지 않을 수 없다. 유지보수하기 편해졌다.

 

그러나, Binding만으로 통신할 수 없는 경우가 분명히 존재한다. 때에 따라서는 Event를 사용해야 할 경우가 분명히 발생한다는 것이다. 이 때 MVVM으로 View를 구성하는 개발자는 알 수 없는 죄책감을 애써 뿌리치며 UserControl .cs코드에 손을 데야 한다. 이 경우 AttachedProperty를 사용하는 등의 고급 기술(ex: BehaviorCommand, TreeView의 SelectedItem TwoWay Binding)로 해결 할 수는 있지만 Binding으로 정복되지 않은 영역이 아직 더 많다. 물론, View cs코드로 View의 세부 동작을 컨트롤 하는 것으로는 느슨한 결합이란 원칙이 깨지지 않는다. 하지만 View 에서 ViewModel을 직접 참조한다던가(이것만으로는 나쁘지 않을 수도 있다), ViewModel에서 View의 특정 UI Element를 참조한다면, 완벽한 느슨한 결합이란 물 건너 간 것이다. 이를 해결하기 위해서는 WPF개발자는 적지 않은 시간을 쏟아 내야 한다. 그리고 그 적지 않은 시간의 열매가 문제의 해결을 보장하지 못한다는 사실에 비극이 있다.

 

또한 Binding 그 자체에서 오는 문제도 분명히 존재한다. Binding으로 느슨한 결합이 완료 되었는지를 확인하려면 실제로 프로그램을 실행해 봐야 한다. , Binding Path에 오타를 적었다고 해도, RelativeSource에 자기가 생각한 Source가 매칭되지 않았다 할 지라도 CompileTime에 에러를 낼 수 있는 방법이 현재로선 없을뿐더러, 런타임에도 Exception을 발생시키지 않는다. 가장 좋은 해법이 Debug Output창에 에러 메시지를 확인 하는 뿐이다. 요는, ViewModel 자체를 별도로 테스트 할 수는 있지만 - 내 경험에서 발견된 사실이지만 - UI동작의 버그는 ViewModel자체에서 뿐 아니라 View ViewModel사이의 연결 때문에(Binding 때문에) 많이 발생 되는데, 이것을 별도로 테스트 하거나 Runtime전에 확인할 방법이 없다는 것이다.

 

또한 MVVMWPF개발자에게 생각보다 많은 WPF의 이해력과 통찰력을 요구한다. 그리하여(당연하겠지만) 이 멋진 디자인 패턴을 이해하고 완전히 적용하려면 적지 않은 노력이 필요하다.

 

 

 

--- 이 후에 계속됩니다

저작자 표시
신고
TAG , ,


 

티스토리 툴바