이번글에서는 마지막 설계 패턴인 MVVM에 대해서 적어볼까 합니다.
MVP의 문제점?
MVP 패턴에서는 Presenter가 View에 어떤 일을 요청하는지 명백히 확인이 가능했습니다.
하지만 Presenter와 View가 1:1 관계를 맺고, 강하게 결합되는 문제점이 있었습니다.
MVVM의 목표
데이터 바인딩, LiveData 또는 RxJava 같은 Observable 타입을 이용하여
Presenter와 View 사이의 강한 의존성을 제거하는 것입니다.
Presenter 대신 Viewmodel이라는 구성요소를 사용합니다.
MVVM의 Components
Model
- 데이터와 데이터에 관련된 행위를 의미합니다.
- 데이터와 데이터를 가져오는 로직 자체를 Model이라고 생각하면 이해하기 편합니다.
특히 MVVM의 Model은 domain 모델을 나타낸다.- domain 모델이란 소프트웨어로 해결하고자 하는 문제 영역을 개념적으로 표현한 것
- 데이터와 데이터를 가져오는 로직 자체를 Model이라고 생각하면 이해하기 편합니다.
view
- 사용자에게 화면으로 보이는 모든 구조, 레이아웃을 View라 부른다.
- View는 Model을 시각적으로 표현하고, 사용자의 상호작용을 받는다.
- View는 Data binding을 통해 이러한 입력을 View model로 전달한다.
- View는 ViewModel을 관찰해야 하기에 바인딩해야 한다(구독해야 한다)
- ViewModel의 상태가 변경되면 그 이벤트를 받아서 UI를 갱신함.
ViewModel
- ViewModel은 View의 추상화된 형태이다. View에 보여야 하는 데이터와 명령들을 가지고 있다.
- ViewModel이 MVC 패턴의 Controller나 MVP 패턴의 Presenter와 다른 점은 View가 Viewmodel을 Observe(관찰)하는 형태로 binding 되어있기 때문에 , data의 갱신을 View가 자동으로 받을 수 있게 된다는 점이다.
- ViewModel은 Model에서 제공받은 데이터를 UI에서 필요한 정보로 가공해서 저장한다.
- ViewModel : View는 1:N관계를 가진다.
- 여러 개의 Fragment가 하나의 Viewmodel을 가질 수 있다.
- ViewModel이 View에 느슨하게 연결되도록 Data Binding 라이브러리가 필수적으로 사용된다.
- 여기서 중요한 점은 ViewModel은 view의 Context에 대한 래퍼런스를 가지면 안 된다는 점이다.
- View는 ViewModel의 래퍼런스를 가지지만, ViewModel은 View에 대한 정보가 전혀 없어야 한다.
(메모리 누수 발생할 가능성이 있다. 이유는 ViewModel이 destory 외의 라이프사이클에서는 메모리에서 해체되지 않기 때문이다)
- View는 ViewModel의 래퍼런스를 가지지만, ViewModel은 View에 대한 정보가 전혀 없어야 한다.
MVVM의 구조
각각의 구성요소는 서로 reference를 갖지 않고 View->ViewModel -> Model 형태의 단방향 의존성을 갖는다.
각 구성요소는 Notify 될 때까지 기다린다.
MVVM의 흐름
흐름을 보면 알 수 있듯이 View는 Model, Model은 View가 어떻게 동작하는지 신경 안 써도 된다.
느낀 점
다양한 설계 패턴이 있고, 내가 제작하려는 애플리케이션과 규모를 생각해서 설계 패턴을 적용하는 것이 매우 중요하다고 느꼈고, 무작정 MVVM, MVP 패턴이 앱 설계에서 좋은 구조는 아니고, 간단한 앱을 만들려는 경우에는 MVC패턴도 적절한 설계 패턴이 된다는 점을 느꼈다.
결국은 애플리케이션 설계에서 가장 중요한 것은 이러한 틀에 휘둘리지 않고 현재 개발하는 애플리케이션에 최적의 구조를 스스로 생각해서 적용할 수 있는 능력이 필요한 것 같다. 그러기 위해서는 다양한 설계패턴을 적용해서 앱을 만들어 보는 것이 중요한 것 같다.
