Architecture) MVP 패턴이란?

MVP 패턴이란?

  • Model(모델), View(UIView/UIViewController), Presenter

Model은 MVC 패턴에서 의미하는 모델과 같은 역할을 한다. 즉, 앱의 실행에 필요한 실질적인 데이터를 갖고 있다.
ViewUIView와 UIViewController가 여기에 해당하며, 비즈니스 로직과 관련된 일은 모두 Presenter가 하도록 한다.
Presenter는 UIKit과 관련이 없는 로직들을 수행하며, 사용자 응답에 반응하거나 UI를 업데이트하는 일을 한다.(비즈니스 로직 관련된 일 수행)

다이어그램

MVP 패턴

  • MVC 패턴과 굉장히 유사한 구조로 이루어져있지만, MVP는 UIView와 UIViewController가 View에 속해있다. (이로인해 MVC에서의 테스팅 한계를 어느정도 극복했다.)

  • MVC에서 UIViewController는 Controller에 해당했고 그로인해 View와 강하게 연결되어 있었지만, MVP에서는 이 둘을 View로 분류하는 대신 Presenter라는 것이 등장한 것이다.

  • Presenter는 View(UIView, UIViewController)의 Life Cycle에 영향을 받지 않고 레이아웃 코드 역시 Presenter에 존재하지 않는다.

  • Controller의 역할답게 View를 데이터와 상태에 맞추어 갱신하는 역할을 갖게 된다. 즉, PresenterModel로 부터 갱신된 데이터를 받아와 뷰를 갱신하는 역할을 한다.

  • 뷰를 갱신하기 위한 메소드를 직접 작성한다던지 각 이벤트에 따른 메소드들을 바인딩해줘야 하는 등의 이유로 개발 비용이 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보다 길어진다.

참고

Author

Sujeong Kim

Posted on

2021-09-29

Updated on

2021-10-05

Licensed under

댓글