Architecture) MVP 패턴이란?
MVP 패턴이란?
M
odel(모델),V
iew(UIView/UIViewController),P
resenter
Model
은 MVC 패턴에서 의미하는 모델과 같은 역할을 한다. 즉, 앱의 실행에 필요한실질적인 데이터
를 갖고 있다.View
는UIView와 UIViewController
가 여기에 해당하며, 비즈니스 로직과 관련된 일은 모두 Presenter가 하도록 한다.Presenter
는 UIKit과 관련이 없는 로직들을 수행하며, 사용자 응답에 반응하거나 UI를 업데이트하는 일을 한다.(비즈니스 로직 관련된 일 수행
)
다이어그램
MVC 패턴과 굉장히 유사한 구조로 이루어져있지만, MVP는
UIView와 UIViewController가 View에
속해있다. (이로인해MVC에서의 테스팅 한계
를 어느정도극복
했다.)MVC에서 UIViewController는 Controller에 해당했고 그로인해 View와 강하게 연결되어 있었지만, MVP에서는 이
둘을 View로 분류
하는 대신Presenter라는 것이 등장
한 것이다.Presenter
는 View(UIView, UIViewController)의 Life Cycle에 영향을 받지 않고 레이아웃 코드 역시 Presenter에 존재하지 않는다.Controller의 역할답게 View를 데이터와 상태에 맞추어 갱신하는 역할을 갖게 된다. 즉,
Presenter
는Model로 부터 갱신된 데이터를 받아와 뷰를 갱신하는 역할
을 한다.뷰를 갱신하기 위한 메소드를 직접 작성한다던지 각 이벤트에 따른 메소드들을 바인딩해줘야 하는 등의 이유로 개발 비용이 MVC보다는 높아진다.
View는 Presenter를 소유하고 있어야 하며 Presenter는 유저 액션, 데이터 갱신, 상태 갱신에 따라 View를 갱신해주어야 한다.
이를 코드로써 구현할 때 View는 Presenter를 강한 참조로 소유하고 있고 Presenter는 약한 참조로 View를 단순히 가리키고만 있는다.
그렇기 때문에 View의 Life Cycle의 영향과 레이아웃 코드와 액션 코드가 공존하는 등의 의존성에서는 벗어날 수 있지만 참조에 의한 1:1 의존성에서는 벗어날 수 없다는 한계가 존재한다.
좋은 아키텍쳐의 기준에 얼마나 부합하는가?
- Distribution - 전통적인 MVC에서 발생한 Model과 View의 의존성 문제는 해결하였다. 참조에 의한 View와 Controller의 의존성은 존재하지만 비교적 셋 모두 역할별로 적절히 나누어져 있다고 말할 수 있다.
- Testability - 각각의 요소를 독립적으로 테스팅하기 용이하다.
- Easy of Use - Presenter의 추가와 이를 구현하기 위한 프로토콜등의 추가로 코드가 MVC보다 길어진다.
참고
Architecture) MVP 패턴이란?