[Architecture Pattern] MVP 패턴

MVC, MVVM 패턴에 이어서, 많이 사용되는 MVP 패턴에 대해서도 공부해보고자 한다. MVP 패턴도 공부해서 이때까지 공부해본 여러 아키텍처 패턴의 특징에 맞게 프로젝트에 적용해보고 싶다.

 

해당 포스팅은 안드로이드 아키텍처 기준으로 작성되었습니다.

 

1. MVP 패턴이란?

MVP 패턴은 Model, View, Presenter 이 세 가지 역할로 어플리케이션(프로그램)을 분리해놓은 것이다.

MVC 패턴과는 한 가지만 다르다. MVC의 Controller 대신에 Presenter가 있다.

 

2. MVP 패턴의 구조

MVP 패턴은 Model, View, Presenter로 구성되어 있다.

 

출처 : laptrinhx(https://laptrinhx.com/how-to-adopt-model-view-presenter-on-android-3112038880/)

 

Model

• 프로그램에서 다루는 데이터를 가지고 있고 그 데이터를 처리하는 부분
• 데이터 처리하는 역할
• 안드로이드에서는 APIClient, Dao 등등

 

View

• UI 부분
• 렌더링하는 역할
• Model의 데이터를 Presenter를 통해 받아 해당 데이터를 화면에 보여주는 역할을 한다.
• 사용자의 입력(Action)을 받는다.
  • 사용자의 입력(Action) : ex)버튼 클릭, 아이템 목록 스크롤 등등
• 안드로이드에서는 Activity, Fragment가 해당

 

Presenter

• Model과 View의 중개자 역할
• View로부터 사용자 이벤트(앱과의 상호작용)을 전달받는다.
• View로부터 전달받은 이벤트에 따라 Model을 호출하기도 한다.
• Presenter와 View는 1:1이다.
• Model로부터 받은 데이터를 View에게 알려 UI를 수정하기도 한다.
• View을 interface로 조작한다.
  • 이때문에 MVC 패턴보다 독립성이 더 크고, 개발 환경 변화에 유연하게 대응할 수 있다는 장점이 있다.
  • MVC 패턴의 Controller는 직접적으로 View와 연결을 한다. 
  • 반면 MVP 패턴은 직접 필요한 것을 주고 받는 것이 아니라, interface를 통해 주고 받는다. 

 

동작순서

1. View로부터 사용자 입력이 들어온다.
2. View는 필요한 데이터를 Presenter에게 요청한다.
3. Presenter는 Model에게 데이터를 요청한다.
4. Model은 데이터를 Presenter에게 전달한다.
5. Presenter는 업데이트된 데이터를 View에게 전달한다.
6. View는 받은 데이터를 화면에 나타낸다.

 

3. 장점

• Model과 View 사이의 의존성이 전혀 없다.
  • 테스트에 더 용이해질 수 있다.
• View와 Presenter는 interface를 통해 상호작용하므로, MVC 패턴의 Controller보다 더 독립적이고 유연하게 모듈화가 가능하다.

 

 

4. 문제점

• 어플리케이션이 복잡해질 수록, View와 Presenter 사이의 의존성이 높아질 수 있다.

 

MVC 패턴에서 더 발전된 것 같지만, MVP 역시 문제점을 갖고 있다.

그래도 MVVM 보다는 설계하기에는 더 쉽지 않을까 생각이 든다.

간단한 로직의 프로젝트에서 테스트를 쉽게 하고 싶다면 MVP 패턴을 적용해야 할 듯 하다.

 

 

참조

• Mobiinside님 브런치(안드로이드 어플리케이션에 MVP패턴을 적용하는 방법)
• 버미노트([디자인패턴] MVC,MVP, MVVM  비교)
• Budhdi Sharma medium(MVP Deep Dive)
• Qiita(StackOverFlowの「MVPとMVCの違い」についての回答を読んでみた)