먼저 작성자는 조치원수호대 프로젝트를 하며 스파게티 코드에 대한 문제점을 발견하였습니다. 그래서 다자인 패턴에 대한 간략한 공부한 결과 모델 뷰 컨트롤러(Model View Controller, MVC) 패턴을 초석으로 보다 모듈화되고 테스트 가능한 패턴으로 발전해 왔으나 모델 뷰 프리젠터(Model View Presenter, MVP)와 모델 뷰 뷰모델(Model View ViewModel, MVVM)은 MVC을 대체하기 위해 가장 많이 쓰이는 두 가지 대안책입니다. 하지만 개발자들은 어떤 것이 안드로이드에 더 적합한지 의견을 일치하지 못했습니다. 따라서 이 글은 다양한 견해를 보고 내린 저만의 결론입니다.

모델, 뷰, 컨트롤러 접근 방식은 애플리케이션을 매크로 수준에서 세 가지 책임 집합으로 분리합니다.

모델은 앱의 데이터 + 상태 + 비즈니스 로직 입니다. 말하자면 앱의 두뇌 역할이죠. 뷰나 컨트롤러에 묶이지 않으므로 많은 곳에서 재사용할 수 있습니다.

뷰는 모델의 표현 입니다. UI를 그리고 사용자가 앱과 상호작용할 때 컨트롤러와 통신하는 책임을 맡습니다. MVC 구조에서 뷰는 하위 모델에 대한 지식이나 상태에 대한 이해가 없고, 사용자가 버튼을 클릭하거나 값을 입력하는 등의 행동을 할 때 무엇을 해야 하는지 모른다는 점에서 상당히 “멍청합니다”. 그 이유는 뷰가 덜 알수록 모델에 종속되지 않으므로 보다 변화에 유연할 수 있기 때문이죠.

컨트롤러는 앱을 묶어주는 접착제 입니다. 애플리케이션에서 발생하는 일을 담당하는 마스터 컨트롤러 역할이죠. 뷰가 컨트롤러에게 사용자가 버튼을 눌렀다고 알리면, 컨트롤러는 그에 따라 어떻게 모델과 상호작용할지 결정합니다. 모델에서 데이터가 변화되는 것에 따라 컨트롤러는 뷰의 상태를 적절하게 업데이트하도록 결정할 수 있습니다. 안드로이드 앱에서는 컨트롤러가 주로 액티비티나 프래그먼트로 표현됩니다.

MVP는 컨트롤러의 책임에 묶이지 않고도 뷰와 액티비티가 자연스럽게 결합하도록 합니다. 더 자세한 내용은 이후에 다루도록 하고, 먼저 MVC와 대비되는 공통 책임 정의부터 시작하겠습니다.

MVC와 동일하며 변화가 없습니다.

유일한 변화는 액티비티/프래그먼트가 이제 뷰의 일부로 간주된다는 것입니다. 따라서 이들이 서로에게 연관되는 자연스러운 현상을 극복할 필요가 없습니다. 액티비티가 뷰 인터페이스를 구현해서 프리젠터가 코드를 만들 인터페이스를 갖도록 하는 것이 좋습니다. 이렇게 하면 특정 뷰와 결합되지 않고 가상 뷰를 구현해서 간단한 유닛 테스트를 실행할 수 있죠.

본질적으로는 MVC의 컨트롤러와 같지만, 뷰에 연결되는 것이 아니라 그냥 인터페이스라는 점이 다릅니다. 이에 따라 MVC가 가진 테스트 가능성 문제와 함께 모듈화/유연성 문제 역시 해결합니다. 사실 극단적으로 MVP를 따르는 사람들은 프리젠터가 절대로 어떤 안드로이드 API나 코드라도 참조해서는 안된다고 주장합니다.

안드로이드의 데이터 바인딩을 사용하는 MVVM은 테스트와 모듈화가 쉽고 뷰와 모델을 연결하기 위해 사용해야 하는 연결 코드를 줄일 수 있다는 장점이 있습니다. 이 후 차트에서 언급할 이야기 지만 MVVM의 꽃이자 정수는 데이터 바인딩 입니다. 데이터바인딩을 사용하지 않으면 MVVM을 사용하지 않은 것이라 할 수 있습니다.

MVC와 동일하며 변화가 없습니다.

뷰는 뷰모델에 의해 보여지는 옵저버블 변수와 액션에 유연하게 바인딩됩니다. 자세한 내용은 이후에 살펴보죠.

뷰모델은 모델을 래핑하고 뷰에 필요한 옵저버블 데이터를 준비합니다. 또한 뷰가 모델에 이벤트를 전달할 수 있도록 훅(hook)을 준비합니다. 그러면서도 뷰모델이 뷰에 종속되지는 않습니다.