[Android] - 안드로이드 설계 패턴(MVP)

이전 글에서는 mvc에 대해서 포스팅했습니다.

https://jja2han.tistory.com/256

[[Android] - 안드로이드 설계 패턴 (MVC)

📕배운 내용 안드로이드 애플리케이션 설계 패턴은 크게 3가지로 분류됩니다. ( MVC, MVP , MVVM) 이번 포스팅에서는 MVC에 대해서 알아볼 예정입니다. 애플리케이션 설계 패턴이 중요한 이유는 이전

jja2han.tistory.com](https://jja2han.tistory.com/256)

이번 글에서는 MVC의 문제점을 해결하기 위해 나온 설계패턴인 MVP에 대해서 적어볼까 합니다.

MVC에서의 문제점!?

그것은 바로 View와 Model의 결합도가 높아서 유닛테스트가 불가능하다는 단점이 있습니다.

그 문제점을 해결하기 위해서 MVP는 Controller가 아닌 Presenter라는 개념을 도입했습니다.

MVP는 Model, View, Presenter로 구성되어 있습니다.

Model과 View의 역할은 MVC구조에서와 유사합니다.

MVP의 목적은 UI(View)와 비즈니스 로직(Model)을 분리시켰다는 것에 있습니다.

이렇게 되면 당연하게 View와 Model의 결합도가 낮아지고, 유닛테스트가 가능해집니다.

설계 구조

Presenter는 View와 Model의 인스턴스를 가지며, View와 Model을 연결해 주는 역할을 하고 있습니다.

View와 Model은 Presenter를 통해서만 데이터를 전달받을 수 있음.

Presenter과 View는 1대1 관계를 갖습니다.

MVP의 흐름

MVP 패턴의 동작 순서는 아래와 같습니다.

1. 사용자의 Action들이 View를 통해 들어옵니다.
2. View는 데이터를 Presenter에게 요청합니다.
3. Presenter는 Model에게 데이터를 요청합니다.
4. Model은 Presenter에서 요청받은 데이터를 응답한다.
5. Presenter는 View에게 데이터를 응답한다.
6. View는 Presenter가 응답한 데이터를 이용하여 화면을 나타낸다.

MVP 디자인 패턴 장단점

장점

1. View와 Model 간의 의존성이 없다.
2. UI/비즈니스 로직을 분리함으로써 유닛 테스트가 수월하다.

단점

1. View/Presenter 간의 의존성이 높고 1:1 관계를 유지해야 하므로, Presenter를 재사용할 수 없음.
   • View가 늘어날 때마다 Presenter도 같이 늘어남.. -> 많은 양의 클래스가 생성
   • 앱의 기능이 추가될수록 Presenter가 거대해짐. --> 유지보수는 여전히 힘들다..

결론

MVP는 MVC의 단점을 해결하기 위해서 등장한 패턴이다.

MVC의 단점인 View와 Model 사이의 의존성은 해결되었지만

(View와 Model은 Presenter를 통해서만 데이터를 전달받는 방식으로)

View와 Presenter 사이의 의존성이 높아지는 단점이 있다.