[Android] 안드로이드 디자인 패턴 - MVC, MVP, MVVM

안드로이드 디자인 패턴에는 크게 MVC, MVP, MVVM이 있습니다. MVC -> MVP -> MVVM 순서로 등장했는데, 이는 각각의 단점들을 해소하기 위해 제시되었습니다. 각각 디자인 패턴의 장단점과 발전 흐름을 정리해보겠습니다.

MVC

MVC는 웹에서 널리 사용되는 디자인 패턴입니다. Model, View, Controller의 3가지 영역을 사용합니다. 사용자의 입력은 Controller에게 발생하고 발생한 입력을 Model에게 전달하여 로직을 처리하며, View가 UI를 Update 하도록 명령합니다. (이후에 UI 관련 로직들이 복잡해지며 View에서 입력을 받는 경우가 많아졌습니다.)

MVC 패턴은 역할을 구분하여 처리하긴 하지만 안드로이드에서 이를 구현할 시 안드로이드의 화면 구성 요소인 Activity 또는 Fragment 클래스에 View와 Controller를 함께 구현해야 합니다. MVC는 구현이 매우 간단하고 빠르다는 장점이 있었지만 View를 변경할 시 Controller에 Controller를 변경할 시 View에 영향을 미치게 되어 유지 보수 및 Test 환경을 구성하기 나쁘다는 단점이 있습니다. 또한 화면을 보여줘야 할 Activity, Fragment 클래스가 지나치게 비대해진다는 단점이 있었습니다.

MVP

MVC 패턴에서 화면을 보여줘야할 View Layer(Activity, Fragment 클래스)가 지나치게 많은 역할을 지니고 있었기 때문에 이를 분리하고 Controller가 하는 일을 Presenter가 대신 하는 방식이 MVP(Model, View, Presenter)입니다. Model이 데이터를 변경할 때 Presenter가 Model를 참조하던 것을 View에게 알려서 UI를 Update하게 하고 사용자의 입력이 일어나 데이터를 변경해야 할 때도 Presenter가 View를 참조하고 있던 것을 Model에게 알리게 됩니다. Model과 View 사이에 Presenter를 두어 Model, View의 상호 의존성을 끊고자 한 것입니다. Presenter는 MVC의 Controller와는 달리 더 이상 UI를 생성하는데 필요한 코드를 가지지 않아도되므로 Test가 가능하게 되었습니다. 다만 UI 관련 코드가 없을 뿐이지 View에 대해 아예 몰라도 되는 것이 아닙니다.

MVVM

Presenter가 View에 대해 알 필요가 없는 독립적인 구조를 만들기 위해 MVVM이 제안되었습니다. MVVM은 Model, View, ViewModel로 이제 ViewModel은 View의 UI 변경에 대해 관여하지 않고 Model에서 받아온 Data 변경에 관련된 사항들을 반영(Data Binding)합니다. View는 UI Update를 위해 ViewModel에서 UI변경에 관련된 Data 값을 Subscribe하고 있다가 변경이 감지되면 이를 UI에 반영합니다. 이렇게되면 View는 ViewModel에 대해 의존성을 가지게 되지만 ViewModel은 View에 대해 의존성을 가지지 않습니다. MVVM은 시스템 또는 사용자가 View단을 제거하는 일이 잦은 모바일에서 유용한데, 만약 애플리케이션이 화면에 보여져야 할 어떤 상태 정보를 MVC 패턴에서 하던대로 Activity나 Fragment 클래스에 저장하게 된다면 짧고 불안정한 생명 주기로 인해 (화면 전환, 강제 종료, 자원 회수) 상태 정보까지 사라질 수 있습니다. ViewModel은 화면 구성요소들보다 긴 생명 주기를 가지도록 구현되어 상태 정보를 저장하는데 쓰일 수 있다는 장점도 있습니다.