WPF 개발자가 MVVM을 선호하는 이유

WPF 개발자가 MVVM을 선호하는 이유
 

개발자가 WPF와 MVVM에 익숙해진 뒤에는 이 둘을 차별화하기가 어려워집니다. MVVM은 WPF 플랫폼에 적합하며, WPF는 여러 패턴 중에서도 MVVM 패턴을 사용하여 응용 프로그램을 쉽게 작성하기 위해 디자인되었기 때문에 MVVM은 WPF 개발자에게는 공용어라고 할 수 있습니다. 실제로 Microsoft에서는 핵심 WPF 플랫폼이 개발 중인 동안 Microsoft Expression Blend와 같은 WPF 응용 프로그램을 개발하기 위해 내부적으로 MVVM을 사용했습니다. 외형이 없는 컨트롤 모델 및 데이터 템플릿과 같은 WPF의 여러 측면에서는 MVVM이 권장하는 상태와 동작으로부터의 강력한 표시 분리를 활용하고 있습니다.

MVVM이 훌륭한 패턴이 되는 데 영향을 미친 WPF의 가장 중요한 측면은 데이터 바인딩 인프라입니다. 뷰의 속성을 ViewModel에 바인딩하면 둘 간에 느슨한 연결을 수행하고 ViewModel에서 뷰를 업데이트하는 코드를 작성해야 하는 필요성을 완전히 제거할 수 있습니다. 데이터 바인딩 시스템은 또한 유효성 검사 오류를 뷰로 전송하는 표준화된 방법을 제공하는 입력 유효성 검사를 지원합니다.

이 패턴을 더욱 유용하게 만드는 WPF의 다른 두 가지 기능으로 데이터 템플릿과 리소스 시스템이 있습니다. 데이터 템플릿은 사용자 인터페이스에 나와 있는 ViewModel 개체에 뷰를 적용합니다. XAML을 사용하여 템플릿을 선언하고 런타임에 리소스 시스템이 자동으로 이러한 템플릿을 찾고 적용하도록 할 수 있습니다. 바인딩과 데이터 템플릿에 대해 더 알아보려면 필자의 2008년 7월 칼럼 "Data and WPF: 데이터 바인딩과 WPF를 사용한 데이터 표시 사용자 지정"을 참조하십시오.

WPF에 명령에 대한 지원이 없었다면 MVVM 패턴의 유용성은 크게 떨어졌을 것입니다. 이 기사에서는 ViewModel가 뷰에 명령을 공개하여 뷰가 해당 기능을 사용할 수 있도록 허용하는 방법을 알아보겠습니다. 명령에 익숙하지 않다면 2008년 9월호에서 Brian Noyes의 기사 "Advanced WPF: WPF의 라우팅된 이벤트와 명령 이해"를 읽어 보십시오.

WPF와 Silverlight 2의 기능을 통해 MVVM을 응용 프로그램을 작성하는 자연스러운 방법으로 사용할 수 있다는 점 외에도 이 패턴이 인기를 모으는 데는 ViewModel 클래스에 단위 테스트를 수행하기가 수월하다는 점이 있습니다. 응용 프로그램의 상호 작용 논리가 ViewModel 클래스의 집합에 있으면 이를 테스트하는 코드를 손쉽게 작성할 수 있습니다. 어떤 의미에서 뷰와 단위 테스트는 ViewModel 소비자의 다른 유형일 뿐입니다. 응용 프로그램의 ViewModel을 위한 테스트 도구를 갖추면 자유롭고 신속하게 회귀 테스트를 수행할 수 있으며 장기적으로 응용 프로그램의 유지 관리 비용을 낮출 수 있습니다.

자동화된 회귀 테스트 작성을 원활하게 하는 것 외에도 ViewModel 클래스의 테스트 용이성은 스킨 사용이 용이한 사용자 인터페이스를 올바르게 디자인하는 데도 도움이 됩니다. 응용 프로그램을 디자인할 때 ViewModel을 사용하는 단위 테스트를 작성하기를 원할지를 생각해 봄으로써 어떤 항목이 뷰 또는 ViewModel 중 어디에 있어야 하는지 결정할 수 있는 경우가 많습니다. UI 개체에 전혀 만들지 않고도 ViewModel에 대한 단위 테스트를 작성할 수 있다면 특정한 시각적 요소에 대한 종속성이 없는 것이므로 ViewModel에 완전하게 스킨을 적용할 수 있습니다.

마지막으로 시각적 디자이너와 함께 작업하는 개발자의 경우 MVVM을 사용하면 손쉽게 매끄러운 디자이너/개발자 워크플로를 만들 수 있습니다. 뷰는 단순히 ViewModel의 임의 소비자일 뿐이므로 간단하게 기존의 뷰를 제거하고 새로운 뷰를 추가하여 ViewModel를 렌더링할 수 있습니다. 단계가 간단하기 때문에 디자이너가 작성한 사용자 인터페이스의 프로토타입 작성과 평가를 신속하게 수행할 수 있습니다.

개발팀에서는 강력한 ViewModel 클래스를 만드는 데 집중할 수 있으며 디자인 팀에서는 사용자에게 친숙한 뷰를 만드는 데 집중할 수 있습니다. 두 팀의 작업 결과를 연결하는 데는 뷰의 XAML 파일에 올바른 바인딩이 있는지 확인하는 것에 약간의 작업이 추가될 수 있습니다.

Model 레이어: Model 레이어는 데이터 자체만 다루고 필요에 따라 애플리케이션에서 어떠한 형태로도 사용되어질 수 있다. View 레이어가 웹 어플리케이션이든 WPF나 실버라이트든 관계없이 Model 레이어는 변경될 필요가 없다.

View 레이어: View 레이어 에서는 시각적 요소에만 집중할 수 있다. 따라서 프로그래밍 경험이 없는 디자이너가 작업을 할 수 있으며 이 과정에서 비즈니스 로직은 변경되지 않는다. 디자이너는 View 레이어의 데이터바인딩과 관련해서 작업을 진행할 때 어떠한 요소와 데이터바인딩이 될 것인지에 대해서만 알면 된다. 실제 데이터와 연관관계가 적기 때문에 개발자와 협업하면서 언제든지 View 형태를 변경하는 작업을 진행할 수 있다.

ViewModel 레이어: ViewModel 레이어에서는 특정 View와 관련되어 있는 것이 아니기 때문에 테스트가 편리하다. 애플리케이션에 특화된 ICommand를 통해 외부로 제공되며 View 레이어 없어도 단위 테스트를 진행할 수 있다.

Model 레이어

• Model은 데이터 객체의 구조 그 자체만 정의한다. 그 외에 어떠한 View를 통해 보여지는지, 어떠한 비즈니스 로직이 필요한지에 대해서는 인실할 필요가 없다.
• 프로그램의 어떠한 형식으로도 사용되어질 수 있고 특정 프레임워크나 기술에 상관없지 폭넓게 사용할 수 있다.

View 레이어

• XAML에 의해서 정의도며 사용자 인터페이스를 담당한다.
• View 레이어에서 필요한 부분은 데이터바인딩에서 Source로 사용되는 속성의 이름만 지정하면 된다. 바인딩된 속성값이 변경되거나 어떠한 명령의 수행이 필요하더라도 이에 대한 구현 부분을 가지고 있지 않다.
• 보여지는 시각적 디자인 요소에 대해서만 정의하며, 비즈니스 로직과 같은 애용을 코드 비하인드 파일에 작성할 필요가 없다.

ViewModel 레이어

• ViewModel은 View 구조에 대해서 알지 못한다.
• Model과 직접 상호 연동하며 데이터 바인딩을 위해 이를 외부로 제공한다.
• ViewModel은 애플리케이션에 특화된 정보를 제공하도록 Model의 데이터를 재구성한다.
• 데이터바인딩을 위해 사용자 인터페이스를 제공하는 View 레이어의 DataContext 속성으로 전달된다.

출처 : http://msdn.microsoft.com/ko-kr/magazine/dd419663.aspx 
http://blog.outsider.ne.kr/672
http://blog.naver.com/vegemilnoid?Redirect=Log&logNo=90125148490