MVP
MVP(Model View Presenter)는 사용자 인터페이스를 구축할 때 이용하는 설계 기법이다.
Model
데이터와 비즈니스 로직이 들어있고, UI에 관한 로직은 가지지 않는다.
데이터베이스나 API 접근에 관한 처리는 여기에 들어간다.
Presenter
모델과 뷰 사이에서 서로 통신한다.
뷰에서 발생한 이벤트가 프레젠터에 알려지면 프레젠터는 그 이벤트에 대응하는 처리.
뷰와 모델 사이에는 항상 프레젠터가 들어간다. 모델이나 뷰의 실체인 인스턴스를 프레젠터로부터 직접 참조하게하지 않고, 인터페이스 등을 이용해 접근할 수 있게 한다.
이렇게 하면 테스트 시에 목 객체(Mock Object)로 대체할 수 있어 테스트하기가 쉬워진다.
MVP 설계의 장점
Model, View, Presenter로 역할을 명확히 나누므로 어느 처리 내용이 어디에 있는지 명확해지고 코드의 관리 효율이 높아진다. MVP패턴으로 설계하면 필연적으로 역할을 나눠야 하기에 액티비티에 구현을 채워넣을 수 없게 된다.
결과적으로 처리를 나눌 수 있어 액티비티를 작게 만들 수 있다. 또한 뷰와 모델 사이에 프레젠터가 들어가므로 뷰와 모델의 의존관계가 없어진다.
MVP 설계의 단점
프레젠터는 인터페이스를 통해 뷰와 모델에 접근하므로 그것들의 위치를 인터페이스로서 정의할 필요가 있다.
이 부분이 길어지기 쉽다. 또한 모델에서 가져온 데이터를 뷰에 표시하는 것을 개발자가 직접 구현해야 한다.
안드로이드에는 기본적으로 MVP 패턴을 지원하는 프레임워크가 없어서 어떻게 UI 로직을 프레젠터로 분리하는가 하는 설계상의 난도가 높다는 것도 단점으로 들 수 있다.
MVVM
Android Gradle Plugin을 통해 데이터 바인딩(Databinding)이 지원된다.
Databinding은 사용자 인터페이스와 데이터를 연결하는(바인딩하는) 메커니즘이다.
데이터 바인딩을 활용한 설계 기법으로 MVVM(Model View ViewModel)이 있다.
모델에는 MVP의 모델처럼 데이터와 비즈니스 로직이 들어간다.
뷰는 데이터를 표시한다. MVP와 달리 ViewModel이 모델에서 가져온 데이터를 반영해서 표시한다.
ViewModel 가진 값이 데이터 바인딩으로 자동적으로 뷰에 반영되므로 뷰 부분에서 반영하는 구현을 할 필요가 없어진다. 하지만 안드로이드에서는 애니메이션이나 액티비티 전환 등 ViewModel에서 구현하기 어려운 항목이 있다. 그런 부분은 뷰에서 구현할 필요가 있다.
기본적으로 ViewModel은 뷰의 상태와 UI에 관한 로직을 구현하고, 데이터 바인딩을 통해 ViewModel의 상태가 뷰에 반영된다. 또한 뷰 클릭 등의 이벤트를 ViewModel이 받고 모델과 데이터를 주고받아 데이터 바인딩으로 뷰의 상태를 갱신한다.
MVVM 설계의 장점
MVP 패턴처럼 역할을 분리할 수 있으므로 액티비티를 작게 만들 수 있다.
데이터 바인딩으로 MVP일 때 기술하는 모델에서 가져온 데이터를 뷰에 반영하는 로직도 작성할 필요가 없으므로 액티비티의 코드를 많이 줄일 수 있다. 프레젠터와 마찬가지로 뷰에 의존하는 코드가 없어 테스트하기 쉽다.
MVVM 설계의 단점
바인딩에 대한 처리는 자동으로 생성되므로 데이터 바인딩 처리는 블랙박스화돼 있다. 자동으로 생성된 코드는 일반적으로 가독성이 낮고 디버그하기 어렵다.
black은 컴포넌트 안을 보거나 변경할 수 없으므로 고안된 대로 재사용이 가능하다.
고안된 대로 쓸 수 있기 때문에 일관된 프로그래밍이 가능하다.
Preference
안드로이드 개발 레벨업 교과서