MVC
MVC 디자인 패턴은 Model, View, Controller 의 줄임말이다.
Controller 는 View 로부터 이벤트가 발생하면 로직에 맞게 Model 을 변경하거나, Model 에서 데이터를 가져와 View 의 상태를 업데이트 하는 역할을 한다.
안드로이드에서 액티비티 혹은 프래그먼트는 View 의 역할을 하는 동시에 Controller 역할도 한다.
구조가 직관적이고 단순하지만 그만큼 코드가 편중되는 경향이 있어 앱의 규모가 커질수록 코드를 유지보수 하기 힘들다.
MVP
MVP 디자인 패턴은 Model, View, Presenter 의 줄임말이다.
Presenter 는 View 와 Model 을 연결해주는 역할로, View 와 Presenter 는 1:1 관계를 가지며, Presenter 를 도입함으로써 UI 로직과 비즈니스 로직을 분리할 수 있게 된다.
UI 로직과 비즈니스 로직을 분리하여 결합도를 낮추게 한 장점이 있지만, View 에서 Presenter 를 직접 생성하기에 의존성이 높고, 1:1 관계를 가지다보니 View 가 많아질수록 Presenter 도 많아지고, 기능이 추가될 때 마다 Presenter 에 코드가 많아짐에 따라 유지보수하기 어려워진다.
MVVM
MVVM 디자인 패턴은 Model, View, ViewModel 의 줄임말이다.
MVP 디자인 패턴의 Presenter 는 View 를 참조할 수 있지만, MVVM 디자인 패턴의 ViewModel 은 View 에 대한 참조가 불가능하다.
ViewModel 을 사용하면 화면 회전과 같이 액티비티가 재성성이 되는 경우에 소멸되지 않고, 액티비티 내에서 finish() 가 호출되는 경우에 onCleared() 가 호출되며 소멸된다.
액티비티 재성성시 데이터를 유지하기 위해서는 onSaveInstanceState() 에서 번들(Bundle)에 데이터를 저장하고, onCreate() 또는 onRestoreInstanceState() 에서 저장한 데이터를 전달 받을 수 있으나 번들은 저장하는 데이터의 자료형과 크기에 제한이 있다는 단점이 있기 때문에 ViewModel 에서 데이터를 관리하는 것이 권장된다.
즉, ViewModel 은 액티비티나 프래그먼트와 별개로 존재하며, 화면 회전 및 다른 구성 변경으로 인한 앱의 재시작에 영향을 받지 않아 데이터 손실을 방지할 수 있다.
또한 ViewModel 은 비즈니스 로직과 UI 로직을 분리시켜 코드 유지보수성이 향상되고, 여러 컴포넌트 간 데이터 공유가 용이해진다.
