What is MVP, MVVP, Model?

안녕하세요. 모바일 개발자라면, 모바일 개발에 관심이 많다면 늘 생각하고 고민하게 되는
디자인 패턴에 대한 이야기를 하는 시간을 가지겠습니다.

늘 공부하는 MVP, MVVM에 대해, Rx를 왜 사용하는지, Model이란 도대체 무슨 역할을 수행하는지에 대해
제 생각을 쭉 써보는 시간입니다.

제가 늘 공부하면서 머리속에 정리되어 있는 내용을 작성하는 포스트이기에
틀린 부분이 있으니 참고하셔서 읽어주세요.

부족하거나 틀린부분을 댓글로 남겨주시면 더욱 발전하는 제가 될 수 있습니다.
많이 많이 부탁드리겠습니다.

Presenter

Presenter는 뷰와 비지니스 모델의 중간다리 역할을 수행합니다.
뷰의 어떠한 이벤트가 발생한다고 한다면 이 이벤트에 대한 비지니스 로직에 대한 결정은
오직 Presenter만이 주관하는 것입니다.
비지니스 로직의 결과 역시 Presenter가 다시 View에게 전달하며
View는 Presenter가 결정한 결과만을 통해 UI를 변경시킵니다.

View는 보통 Android에서는 (View + Activity)
iOS에서는 (View + ViewController)의 모양을 취하고 있습니다.

여기서 Presenter는 View + Activity 또는 View + ViewController를 참조하는 것이 아니라
Activity가 ViewController가 어떠한 비지니스 로직의 결과를 통해
UI를 이벤트 기반으로 참조할 수 있는
해당 뷰의 Delegate를 인터페이스, 프로토콜로 구현하여 이를 Presenter가 참조하여야 합니다.
결국 Presenter는 Model 그 자체, View 그 자체를 가지고 있는 것이 아니라
Model의 다양한 동작을 추상화시킨 인터페이스, 프로토콜
View의 다양한 동작을 추상화시킨 인터페이스, 프로토콜을 가지고 있어야 합니다.

ViewModel

ViewModel은 Rx의 도움을 받습니다.
기존의 Presenter가 동작하는 행동을 Rx스럽게 변경시킨 것이 ViewModel이라고 생각합니다.

ViewModel이 하는 동작은 Presenter와 비슷하지만 확실하게 다릅니다.
뷰의 어떠한 이벤트가 발생하면 이 이벤트에 대한 비지니스 로직의 결정은 ViewModel이 담당합니다.
하지만 비지니스 로직의 결과를 다시 View에게 반환하지 않습니다.

이것이 바로 Presenter와 ViewModel의 차이이며
이 차이로 인해 ViewModel의 재사용성은 증가합니다.

Presenter가 추상화 된 View를 사용한다고 하더라도
각각의 View가 사용하는 동작이나 비지니스 로직의 요청이 다르기에
추상화 된 View의 재사용성이 많이 줄어듭니다.

그렇기에 ViewModel은 View에게 비지니스 로직의 결과를 직접적으로 바인딩 시키지 않습니다.
바인딩 작업은 View가 주관적으로 처리하는 것입니다.

View는 ViewModel을 관찰하고 있습니다. "내가 A라는 요청을 하였는데 결과가 잘 들어왔나?"
ViewModel은 Observable을 가지고 있습니다.
Rx에서 Observable은 관찰가능한 데이터의 흐름을 나타냅니다.
View는 바로 ViewModel의 Observable을 관찰하는 것입니다.

ViewModel은 비지니스 로직의 결과를 Observable하게 만들어 놓습니다.
단지 그 역할만을 수행하는 것입니다.

View는 결과를 ViewModel에서 관찰하면서 데이터가 들어왔다면
View는 해당 데이터를 통해 UI를 변경시킵니다.

이러한 MVVM모델은 재사용성이 MVP보다 높습니다.
같은 데이터를 사용하는 서로 다른 두 View는 같은 데이터를 참조하여 UI를 변경시키기에
불필요한 함수들이 줄어들며 재사용성이 가능하게 만드는 것이죠.

MVVM은 무조건적으로 Rx가 필요하지 않습니다.
Swift의 프로퍼티 감시자를 통해 View에게 값을 넘겨 줄 수 있으며
ViewModel의 Delegate를 View가 구현하여도 충분히 값의 변화를 View가 인지하고
View 스스로가 값에 대한 바인딩 처리를 할 수 있을 것입니다.

하지만 많은 기업이나 사람들이 Rx를 사용하는 이유는

1. Rx의 다양한 리액티브 연산자를 보다 쉽게 사용할 수 있습니다.
2. Rx는 다양한 언어를 지원하기에 리액티브에 대한 이해만 있다면
   같은 코드를 다양한 플랫폼에서 작성할 수 있습니다.
3. 추가적으로 Rx를 사용하면 Error 처리를 한 곳에서 모아서 해결할 수 있습니다.

Model

MVC, MVVM, MVP, 에서 Model라고 표현하는 이 부분!
이 부분을 데이터의 구조를 선언하는 데이터 클래스로서 사용하시는 분들도 있지만
저는 Model을 데이터의 구조만을 선언하는 부분은 절대 아니라고 생각합니다.

저도 역시 MVP, MVVM을 개발하면서 위의 생각으로 개발한 적이 있습니다.
(그 결과 MVP나 MVVM이 MVC가 되는 마법이 일어나는 것 같았습니다...)
View는 UI작업와 바인딩 작업, ViewModel이나 Presenter는
데이터를 바탕으로 비지니스 로직을 구현하는 부분으로 변경되게 되는 모델이 되었습니다.

Model은 비지니스 로직을 구현하는 곳입니다.

만약 데이터 구조만을 선언하는 데이터 클래스는 Model이라는 이름이 아니라
Entity나 Object라는 새로운 이름으로 불러주었으면 좋겠습니다.

Model은 Entity를 이용하여 비지니스 로직을 구현하는 부분이라는 것입니다.

드로이드나이츠에서 레이니스트의 CTO 황성현님의 발표를 보시면
비지니스 로직을 구현하는 Model파트 만을 위한 디자인 패턴에 대해 소개해주셨습니다.
Clean Architecture - 레이니스트 황성현

이 내용을 바탕으로 보다 효율적인 코드를 고려하시는 개발자가 되셨으면 좋겠습니다.

마치며

원래는 Presenter와 ViewModel의 차이를 혼자 정리하려고 노트를 작성했는데
흥분해서 설명 블로그 포스트를 써버렸네요.
제가 가지고 있는 생각이나 의견을 정리하는 포스트이기에 오역이 있을 수 있습니다.
참고하시면서 봐주세요.

댓글이나 질문은 언제나 환영입니다.
마음껏 올려주세요.

긴 글 끝까지 읽어주셔서 감사합니다.