위 글에서 이어지는 내용입니다.
안드로이드 앱 개발 시 다들 MVP, MVVM 패턴을 사용하는데 이게 뭔지! 알아보겠습니다.
배경
액티비티에 UI, data 접근 로직을 다 넣어두면 어떻게 될까요? UI, data에 강한 결합을 가져 확장, 유지보수에 어려움이 있습니다.
쉽게 확장 가능하고 유지 가능하려면 layer를 잘 분리해야 합니다.
즉, View를 data source와 독립적으로 구성해야 합니다!
이렇게 구현하면
- logic의 재활용
같은 logic이 완전히 다른 화면에서 똑같이 쓰일 수 있도록
- logic을 view로부터 완전히 떼어내 쉽게 테스트 가능
을 기대할 수 있습니다.
Presentation layer 패턴
"Presentation layer를 logic과 분리하자" 라는 목표로 여러 Presentation layer 패턴이 제안되었습니다. 그 중 MVP와 MVVM에 대해 설명하겠습니다!
MVP
Model + View + Presenter로 구성
- Model
gateway to domain layer(비즈니스 로직 포함)
즉, View에 보여줄 data 제공자 역할을 하는 부분
- View
보통 Activity, Fragment로 구현되며 Presenter를 참조
사용자의 액션이 들어오면 Presenter에 전달하는 역할(by calling presenter's method)
- Presenter
View와 Model 사이의 중개자(data를 Model에서 받으면 View에 맞게 formatting 등 == Presentation logic) 👉 View, Model 사이에 의존성이 없어짐
View를 참조하며 View와 유저의 interaction이 일어나면 무엇을 할지도 결정함
따라서, 다음과 같이 관계를 표현할 수 있습니다
View-Model 사이의 의존성은 없지만 View와 Prensenter 사이에 강한 의존성이 존재합니다. 이 의존성은 앱에 기능이 많아질수록 커져 Presenter에 구현된 Presentation logic을 재활용하기 어려워집니다!
MVVM
Model + View + ViewModel로 구성
각 부분의 역할은 MVP(Presenter, ViewModel: Presentation logic 구현)와 유사합니다. 단, View - Presenter, View - ViewModel 사이의 관계에 차이가 있습니다!
- View - Presenter
1:1로 강한 결합을 가져 Presenter를 재활용하는 데 어려움이 있음
- View - ViewModel
ViewModel은 View를 참조 하지않음. View가 ViewModel을 구독해 관찰하는 구조로 느슨한 결합을 가짐!
또, ViewModel을 data converter로 봐 그 단위를 data로 함. 따라서, 특정 data가 여러 View에서 사용된다면 관련 logic이 담긴 ViewModel을 재활용할 수 있음!(SRP 만족)
MVP보다 MVVM이 낫다 아니다를 따지진 않고 앱의 특성에 맞게 구현해야합니다~
ref.
https://antonioleiva.com/mvp-android/
https://antonioleiva.com/architecture-components-kotlin/