MVC와 유사한 형태를 가지지만, 분명한 차이점이 있다.
MVP = Model + View + Presenter
Model
MVC와 Model과 동일한 개념.
비지니스 모델 개념과 유사하다.
다음의 3가지 개념이 Model 의 핵심이다.(데이터, 상태, 비지니스로직)
만약 당신이 예약 플랫폼 앱을 개발한다면, 예약이 제일 중요한 Model 이 될것이다.
이 예약에는
- 예약시간
- 예약하는 사람수
- 선주문 내역
- 등등..
이러한 데이터들을 포함 할것이다.
위의 중 ‘선주문 내역’은 할수도(true), 안할수도(false) 있다. = 상태를 가지고 있다.
위의 중 ‘선주문 내역’은 할지 안할지 물어본다.(비지니스로직)
View
MVC에서와 마찬가지로 UI 요소를 담당한다.
하지만 이제 Activity와 Fragment도 View로 분류한다. (MVC 에서는 xml 파일을 View로 분리했음)
UI 갱신과 같은 작업을 View에서 직접 처리해야 하기 때문이다. 왜 그렇냐면 다음의 Presenter의 역할을 보면 이해가 될 텐데 Presenter가 UI 갱신을 View에 요청하기 때문이다.
MVC에서는 Controller 역할을 했던 Activity 또는 Fragment에서 UI 갱신을 한다. 그 역할을 하던 것들이 View로 분류되었으니 View에서 UI 갱신을 하게 된 것으로 생각하면 된다. Controller가 했던 역할이 하나 더 있는데 바로 Model과 상호작용이다.
그러나 이제 그 역할을 하던 Activity와 Fragment가 View에 속했으니 Model과 상호작용은 직접 하지 않는다. 대신 그 역할은 Controller처럼 View와 Model 사이의 가교 역할을 하는 Presenter에게 맡긴다.
- MVC = Model(model) + View(xml) + Controller(Activity or Fragment)
- MVP = Model(model) + View(xml + Activity or Fragment) + Presenter
따라서 View와 Presenter 간에 의존성이 생긴다. 이때 Presernter와 Activity가 직접 연결되지 않도록 View interface를 만들고 Activity가 implements 하여 해당 interface로 연결하면 가상의 View interface로 가상의 객체를 만들 수 있어 Presenter 로직 테스트에 용이하다.
Presenter
MVC의 Controller의 역할과 유사하다. Model과 상호작용하고 View에 UI 갱신을 요청한다.
다만 직접 UI를 갱신하는 것이 아니라 어떤 걸 보여줘야 하는지에 대한 정보만 View에 전달한다. 실제 UI 갱신은 View에 맡기는 것이다. 이 말인즉슨 Presenter는 Controller와 다르게 View와 직접적으로 연결되는 것이 아니라 가교 역할만을 한다는 것이다.
그림을 보면 View와 Model은 서로 분리되어 있는 것을 알 수 있다. 또한 Model은 종속되는 곳이 없기 때문에 테스트하기 쉽고 재사용하기 용이하다. 그러나 Presenter 입장에서는 View와 Model에 대한 의존성이 생긴다. View 또한 Presenter와 의존성이 생긴다. Presenter와 View는 서로 의존성을 갖는 것이다. MVP의 문제점도 결국 Controller와 비슷한 역할을 하는 Presenter에 많은 코드가 쌓이게 될 가능성이 높다는 것이다.
