[Android] MVP와 MVVM 설계 기법

 

액티비티에 계속해서 처리 내용을 기술하다가 액티비티가 너무 커지면 다음과 같은 문제가 발생합니다.

 

● 역할별로 처리가 나뉘지 않아 코드를 읽기가 어렵다

● 다양한 구현이 저마다 멤버 변수를 수정하면 수정했을 때의 영향을 예측하기 어렵다.

 

이러한 문제점에 대처할 수 있는 MVP나 MVVM 등과 같은 설계 기법이 주목 받고 있습니다.

 

MVP

MVP(Model View Presenter)는 사용자 인터페이스를 구축할 때 이용하는 설계 기법입니다. MVP는 Model View Presente의 머리글자로, 이 구현에 따라 모델(Model)과 뷰(View) 프리젠터(Presenter)라는 세 가지 역할로 처리를 나눌 수 있습니다.

 

 

 

 

 

모델(Model)

모델에는 데이터와 비즈니스 로직이 들어 있고, 이곳에서는 UI에 관한 로직은 가지지 않습니다. 데이터베이스나 API 접근에 관한 처리는 여기에 들어갑니다. 

 

뷰(View)

뷰(안드로이드 뷰가 아님)는 데이터를 표시합니다. 또한 사용자의 탭 등 액션은 뷰에서 처리하지 않고 프리젠터에 위임합니다.

 

프레젠터(Presenter)

프리젠터는 모델과 뷰 사이에서 서로 통신합니다. 뷰에서 발생한 이벤트가 프레젠터에 알려지면 프레전터는 그 이벤트에 대응하는 처리, 예를 들어 모델에 접근하거나 합니다. 

 

뷰가 직접 모델에 접근하거나 반대로 모델이 뷰에 직접 접근하는 일 없이, 뷰와 모델 사이에는 항상 프레젠터가 들어갑니다. 모델이나 뷰의 실체인 인스턴스를 프레젠터로부터 직접 참조하게 하지 않고, 인터페이스 등을 이용해 접근할 수 있게 합니다. 이렇게 하면 테스트 시에 목 객체(Mock Object)로 대체할 수 있어 테스트하기 쉬워집니다.

 

MVP 설계의 장점

모델, 뷰, 프레젠터로 역할을 명확히 나누므로 어느 처리 내용이 어디에 있는지 명확해지고 코드의 관리 효율이 높아집니다. MPV 패턴으로 설계하면 필연적으로 역할을 나눠야 하기에 액티비티에 구현을 채워넣을 수는 없게 됩니다. 결과적으로 처리를 나눌 수 있어 액티비티를 작게 만들 수 있습니다. 또한 뷰와 모델 사이에 프레젠터가 들어가므로 뷰와 모델의 의존관계가 없어집니다.

 

MVP 설계의 단점

프레젠터는 인터페이스를 통해 뷰와 모델에 접근하므로 그것들의 위치를 인터페이스로서 정의할 필요가 있습니다. 이 부분이 길어지기 쉽습니다. 또한 모델에서 가져온 테이터를 뷰에 표시하는 것을 개발자가 직접 구현해야 합니다. 안드로이드에는 기본적으로 MVP 패턴을 지원하는 프레임워크가 없어서 어떻게 UI 로직을 프레젠터로 분리하는가 하는 설계상의 난도가 높다는 것도 단점으로 들 수 있습니다.

 

 

 

MVVM

MVVM(Model view ViewModel)은 데이터 바인딩(DataBinding)을 활용한 설계 기법으로 MVP등과 같이 UI 로직을 분리할 수 있습니다.

 

모델에는 MVP의 모델처럼 데이터와 비즈니스 로직이 들어갑니다.

 

뷰는 데이터를 표시합니다. MVP와 달리 ViewModel이 모델에서 가져온 데이터를  반영해서 표시합니다. ViewModel이 가진 값이 데이터 바인딩으로 자동적으로 반영되므로 뷰 부분에서 반영하는 구현을 할 필요가 없어집니다.

 

하지만 안드로이드에서는 애니메이션이나 액티비티 전환 등 ViewModel에서 구현하기 어려운 항목이 있습니다. 그런 부분은 뷰에서 규현할 필요가 있습니다. 기본적으로 ViewModel은 뷰의 상태와 UI에 관한 로직을 규현하고, 데이터 바인딩을 통해 ViewModel의 상태가 뷰에 반영됩니다. 또한 뷰 클릭 등의 이벤트를 ViewModel이 받고 모델과 데이터를 주고받아 데이터 바인딩으로 뷰의 상태를 갱신합니다.

 

MVVM 설계의 장점

MVP 패턴처럼 역할을 분리할 수 있으므로 액티비티를 작게 만들 수 있습니다. 또한 데이터 바인딩으로 MVP일 때 기술하는 모델에서 가져온 데이터를 뷰에 반영하는 로직도 작성할 필요가 없으므로 액티비티의 코드를 많이 줄일 수 있습니다. 프레젠터와 마찬가지로 뷰에 의존하는 코드가 없어 테스트하기 쉽습니다.

 

MVVM 설계의 단점

바인딩에 대한 처리는 자동으로 생성되므로 데이터 바인딩 처리는 블랙박스화돼 있습니다. 자동으로 생성된 코드는 일반적으로 가독성이 낮고 디버그하기가 어렵습니다.