디자인 아키텍처 2 - MVP

MVP는 MVC에서 View와 Model의 결합도가 높다는 단점을 보완하기 위해 만들어진 패턴이다. MVC에서 View는 Activity와 Fragment 그 자체이지만 MVP에서는 View가 Activity와 Fragment는 그 일부일 뿐이고 MVC에서의 Controller의 역할을 View가 담당하여 유저 액션 이벤트를 Presenter로 전달하는 역할을 한다.

View와 Model이 Presenter를 통해서만 동작 하도록 함으로써 View와 Model의 의존성을 제거한다. 아래의 그림과 같이 MVP 패턴의 View는 Model을 직접 호출할 수 없으며 Model은 View에게 바로 데이터를 전달할 수 없다.

MVP 구조

MVP Flow

1. View에서 유저가 이벤트를 발생
2. View는 Presenter로 전달
3. Presenter에서 로직을 처리함
4. Presenter에서 로직을 처리할 때 데이터에 변화가 있으면 Model을 업데이트하거나, Model에서 데이터를 가져옴
5. Presenter에서 View를 업데이트 함

- Model

• 데이터, 상태, 비즈니스 로직을 수행
• View, Presenter 등 어떤 요소에도 의존적이지 않은 독립적인 존재

- View

• 실제 xml, Activity, Fragment에 직접 접근
• Presenter를 이용해서 데이터를 주고받으므로 Presenter에 의존적임
• Presenter에 이벤트 전달

- Presenter

• Model과 View 사이의 매개체
• View와 Model 사이에서 데이터 전달

MVP 장점

Model과 View 간의 결합도를 낮추며, 새로운 기능 추가 및 버그 발생을 하면 해당 부분만 추가 및 수정할 수 있음으로써 코드의 확장성과 유지 보수가 효율적으로 진행될 수 있다. 그리고 UI, Data 담당하는 파트가 명확하게 나뉘어 있어 빠르게 개발이 가능하다.

MVP 단점

가장 큰 단점은 MVP 역시도 View와 Prsenter 사이의 의존성이 강하다는 것이다. 개발 초기 단계에서는 별 문제가 없지만 앱의 부피가 커지면 커질수록 Presenter에 집중도가 강해져 Presenter에서 문제가 발생 시에는 아이러니하게 유지보수가 반대로 어려워지는 문제가 있다.

View와 Model이 Presenter를 통해서만 동작하도록 함으로써 View와 Model의 의존성을 제거한다. 아래의 그림과 같이 MVP 패턴의 View는 Model을 직접 호출할 수 없으며 Model은 View에게 바로 데이터를 전달할 수 없다.