• [안드로이드] Clean architecture
• [안드로이드] 안드로이드에서의 클린 아키텍처

위 글에서 이어지는 내용입니다.

안드로이드 앱 개발 시 다들 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로 구성

• 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/