MVVM이 WPF를 비롯한 XAML 기반 플랫폼에서 중요하게 자리 잡고, 계속해서 발전해온 것에는 여러 가지 이유가 있습니다.
DataContext
XAML GUI 바인딩의 가장 핵심 요소인 DataContext 바인딩을 통해, 이 DataContext가 미치는 모든 영역에서 Binding을 손쉽게 할 수 있게 됩니다. 만약 MVVM 기반을 사용하지 않는다면, 이 멋진 DataContext 개념을 제대로 사용할 수 없게 됩니다. 따라서 원하는 부분의 DataContext를 정교하게 관리하는 것이 중요하기 때문에 ViewModel 방식의 개발이 계속해서 선호되고 있습니다.
RelativeSource
WPF는 모든 컨트롤 요소에 DataContext를 설정할 수 있기 때문에, RelativeSource를 통한 계층 탐색이 다양한 상황에서 매우 효과적으로 사용됩니다. 이 역시 MVVM 구조가 아니라면 사용이 컨트롤 요소로만 제한되기 때문에, RelativeSource의 장점을 온전히 활용하려면 MVVM 구조가 필요합니다.
ICommand
Command 바인딩은 ItemsControl 등과 같은 하위 자식 구조에서 RelativeSource와 함께 활용하여 계층적 활용(탐색)을 극대화할 수 있습니다. 다만, 이 또한 ViewModel 구조가 없다면 제한적이고, 사실상 제대로 사용할 수 없게 됩니다.
이 정도만 놓고 봐도 XAML 특성(장점)을 꽤 잃게 됩니다.
반대로 MVVM 개발방식의 단점들도 많이 있습니다. 하지만 다양한 장점들이 단점들을 상쇄하기 때문에 지속적으로 발전해왔던 것이고, CommunityToolkit.Mvvm, Prism과 같은 프레임워크 라이브러리를 통해 계속해서 단점들이 보완되어 왔습니다.
정리하며
MVVM 관련 중요하게 생각해 볼만한 몇몇 요소들을 한번 간추려봤습니다. 물론 이러한 개발 방식에 부담을 느낄 필요는 없습니다. 저도 개인적으로 수년간 MVVM 기술 의존 없이도 재미있게 개발했었고, 실제 현업에서도 MVVM 없이, 심지어는 코드비하인드만으로 만들어진 프로젝트도 꽤 많이 봐왔습니다.
또한, 일반적인 전통 방식으로도 다양하게 개발해본 경험이 아주 좋은 자산이 되었습니다.
사실 MVVM의 사용 유무, 그리고 사용 방법보다도 XAML의 주요 메커니즘 특성을 이해하는 것이 더 중요하다고 생각합니다. 중요한 키워드는 고작 10개 정도밖에 안됩니다. 이 안에 WPF를 비롯한 모든 XAML 크로스플랫폼의 메커니즘을 관통하는 요소들이 다 얽혀 있으니, 본질에 대해 더 비중 있게 관심 갖고 살펴보시기를 권합니다.
- DataContext
- RelativeSource
- DependencyProperty
- Control
- ContentControl
- ItemsControl
- Template
- ContentTemplate
- ItemTemplate (ContentPresenter)
- DataTemplate
- IValueConverter
결국 MVVM은 이런 XAML의 특성을 가장 잘 활용할 수 있도록 도와주는 개발 방법일 뿐입니다.
먼저 XAML의 본질적인 구조와 메커니즘을 이해하고 나면, MVVM은 자연스럽게 필요성을 느끼게 될 것이고, 훨씬 수월하게 받아들일 수 있을 것입니다.
)
MVVM은 “뷰 우선” 패턴인가요?
요약하자면, MVVM은 “우선순위 구조”로 해석되기보다는 각 계층의 책임 분리와 바인딩 구조로 이해하는 것이 더 정확하며, 이를 Blazor나 다른 프레임워크에 적용할 때도 핵심 원칙에 대한 이해가 선행되어야 한다고 생각합니다.