1. MVVM 구조 및 구성 요소
MVVM 패턴은 Model, View, ViewModel의 앞 글자를 따서 지어졌다.
Model
모든 아키텍쳐 패턴의 Model 부분은 동일한 역할을 수행한다. 아래 포스팅의 Model 부분을 통해 확인할 수 있다.
2021.11.30 - [[SW Engineering]] - 아키텍쳐 패턴 적용하기 : MVP
View
사용자에게 보여지는 화면을 뜻하는 것으로 안드로이드의 Activity와 Fragment인 UI와 관련된 클래스이다. UI에 관련된 부분만 다루기 때문에 사용자가 화면을 통해 보는 것들에 대한 구조, 레이아웃, 형태를 정의한다. View에는 Animation과 같은 UI 로직을 포함하되 비즈니스 로직은 포함하지 말아야 한다. 이전 아키텍쳐 패턴들에 비해 MVVM에서의 View는 능동적 (Active)이다. View는 스스로 ViewModel을 관찰 (Observe) 하며 데이터의 변경이 있으면 가져와 업데이트한다. MVVM에서 LiveData 또는 RxJava의 Observable을 사용하는 이유이다.
ViewModel
View와 Model 사이의 중재자 역할을 한다. View의 모든 Event를 받아 Model에 데이터를 요청한다. ViewModel에는 View가 사용할 Method와 Field를 구현하고 상태 변화가 있을 경우 View에 상태 변화를 알린다. 이때, ViewModel에서 제공하는 Method와 Field는 UI에서 제공할 기능을 정의한다. ViewModel은 View에서 쉽게 사용할 수 있도록 데이터를 가공하여 제공하기만 한다. 이러한 이유로 View는 ViewModel을 알고 있지만 ViewModel은 View를 알지 못한다. 또한, ViewModel과 View는 1:N의 관계를 가지며 여러개의 Activity 또는 Fragment가 하나의 ViewModel을 가져 데이터를 가져올 수 있다.
2. DataBinding : View와 ViewModel 간의 의존성 제거
View가 ViewModel을 감지 후 화면을 갱신해야 한다. 이렇게 관찰로 인한 서로간의 의존적 형태를 지속시키기 때문에 유지보수성을 높이는 데는 한계가 있다. 이를 해결하기 위해 안드로이드에서는 DataBinding을 사용하여 View와 ViewModel 간의 의존성을 제거한다.
MVVM 패턴으로 앱을 개발하면 DataBinding 라이브러리를 쓰는 것을 꼭 고려하는 것이 좋다. DataBinding을 사용하면 View의 의존성을 Activity 및 Fragment 의존에서 XML 의존으로 내릴 수 있으며 XML의 UI 구성요소와 데이터를 바인딩할 수 있도록 제공한다. 또한, View와 ViewModel 간의 데이터와 명령을 연결해주는 매개체 역할을 하게 되어 서로의 존재를 명확히 알지 못해도 다양한 Interaction을 돕는다. DataBinding을 통해 View와 ViewModel의 의존성을 낮춤으로써 UnitTest를 더욱 쉽게 할 수 있게 되었다.
3. MVVM의 장 단점
Model과 View, ViewModel과 View 사이의 의존성을 제거했기 때문에 UnitTest가 더 쉬워졌다. 또한 UI 코드는 더 이상 네이티브 코드에 관여하지 않고 모듈화를 통해 보일러플레이트 코드를 최소화 할 수 있게 되었다.
하지만, 간단한 UI를 갖는 앱에서는 오히려 ViewModel을 설계하는 것이 어려울 수 있다. 또한, View와 ViewModel간의 의존성을 제거하기 위해 DataBinding이 필수적으로 요구된다.
References
https://docs.microsoft.com/ko-kr/windows/uwp/data-binding/data-binding-and-mvvm
'SW Engineering > Architecture Patterns' 카테고리의 다른 글
(Architecture) MVP (0) | 2021.11.30 |
---|