MVVM은 뭐고 MVP는 또 무엇인가

귀여운 얼굴 뒤에 가려진 거대한 존재...안드로이드

요즘 IT 기업, 스타트업의 AOS 개발자 공고를 눈여겨 보고 있다. 가고 싶다. 그런데 지원 자격에 자주 등장하는 키워드들이 있다.

• MVVM, MVP, MVI 경험
• AAC
  ...
• java, kotlin, ReactiveX, MVVM 경험
  ...

MVVM, MVP, 그리고 MVI는 무엇인가?
내가 지금까지 배운 것을 다시 정리해보고자 한다.

디자인 패턴

나에게 그런 패턴 따윈 없다..

MVVM, MVP의 공통점은 디자인 패턴 이라는 것이다. 그럼 디자인 패턴이란 무엇인가?

디자인 패턴이란 똑똑한 사람들이 모여 "이런 방식으로 개발하면 좋아!" 라고 설명한 지침서(?)이다.

간단한 검색 앱이나 기타 등등을 개발할 때는 괜찮지만, 앱이 커질수록 관련 클래스와 기능들이 넘치기 시작한다. 이때 코드들을 잘 정리해두지 않으면 기능들이 일명 스파게티 코드가 된다.
그러면 모듈 테스트도 힘들어지고, 기능을 추가로 도입해야할 때 막막해진다.

그래서 대표적으로 MVC패턴이라는게 있다.

MVC

Spring을 공부할 때 써보게 되었는데, 간단하게 말하자면

C(controller)가 M(model), V(view)에게 명령하는 패턴이다.

뷰와 모델이 각자 역할에만 집중할 수 있게 해서 프로젝트의 기능 결합도(?)를 낮춘다.

안드로이드에서도 MVC패턴을 사용하려고 했다. 근데 문제가 생겼다. 안드로이드의 View인 Activity에서 Controller를 분리하기 힘들었다! xml과 Activity는 강하게 결합되어 있어 View라고 칭하자니, 버튼 클릭시 처리할 메소드도 같은 Activity에서 구현하므로 Controller도 된다는 문제가 생겼다.

MVP

그래서 MVP를 사용하기로 했다. Controller 대신 Presenter를 사용한다.

큰 틀은 같지만, Presenter는 뷰에 연결되어 있는 것이 아닌, 단순 인터페이스라는 점이다.

그래서 결합도를 떨어뜨리고, 가상 뷰를 만들어서 유닛 테스트를 가능하게 한다. View와 Presenter가 1:1 대응된다는 특징이 있다.

그럼 MVP의 문제는 무엇인가?
Presenter 역시 비즈니스 로직이 쌓이면 Controller처럼 유지보수가 어려워진다.

MVVM

MVVM은 MVP의 양방향 의존성을 개선한 패턴이다.
View(UI), ViewModel(Logic), Model(DB)로 구성된다.

View->ViewModel->Model 형태로 호출할 수 있다.

MVC와 다른 점은 ViewModel에서 데이터가 변경될 때 View에게 안 알려줘도 된다는 점이다. MVP에서 Presenter는 Model로 데이터를 갱신 후 View에게 데이터가 바뀌었으니 UI를 바꿔! 라고 알려줘야한다. 근데 Presenter가 알려주는 걸 까먹는다면...?


MVVM은 그런 걱정을 할 필요가 없다.

😳 어째서?

View가 ViewModel의 데이터 변경을 관찰(Observer)하고 있기 때문이다.

🤔 어떻게?

LiveData로!

... 그럼 LiveData는 무엇인가
정말 간단하게 설명하자면, 데이터 변경을 관찰할 수 있는 클래스이다. 안드로이드의 Lifecycle을 감지하고 있기 때문에, START, RESUMED 상태일 때만 데이터를 갱신한다.
자세한 설명은 좀 더 공부한 후에...

이 아이 덕분에 ViewModel은 View에게 UI 변경을 요청 안해도 되고, 최신 데이터 유지와 memory leak 문제를 해결할 수 있게 되었다.

아무튼, MVVM 패턴 사용을 위해 항상 나오는 아이들이 있는데

DataBinding, LiveData, Room이다. 같이 쓸 때 진가를 발휘한다는데 나는 토이 플젝으로 이제 막 써보고 있기 때문에 잘 모르겠다. 나도 빨리 그 진가 를 공감하고 싶다..

디자인 패턴에는 정답이 없다. 프로젝트 성격에 따라 알맞는 것을 선택해 사용하면 된다.