소개

MVP는
ModelView（View,ViewController）Presenter
세 가지로 구성되어 있습니다. MVC 에서는 View 와 ViewController 는 나누어 생각되고 있었습니다만, MVP 에 있어서는 View 로서 다루어집니다.

왜 MVP인가?

MVC 에서는 ViewController 의 책무가 커져 버리기 때문에, 테스트의 용이성이나 작업 분담의 용이함과 같은 문제가 있습니다. 그것을 해결하는 방법은 MVP입니다. 이하에서는, MVP 에 있어서의 역할 분담을 MVC 와 섞으면서 확인해 갑니다. (또한 이번은 MVP 중에서도 PassiveView 패턴을 취급합니다.)

MVC

모델

· 비즈니스 로직 담당

보기

・화면의 묘화 처리

컨트롤러

· View의 입력에 대해 처리합니다 (Controller・ View 에 처리를 의뢰한다 ( Model 는 Controller 에 의존 )
・ Model 의 정보를 취득하기 위해서 API등에 문의한다 ( Model 는 Controller 에 의존)

이상과 같이 Utility 에 있어서 MVC 는 많은 로직이 담겨져 있어, 안는 책무가 많아져 버립니다. 또는 Controller 는 Controller , View , Model 에 의존하기 때문에 작업 분담이나 테스트의 용이성이라는 점에서 문제가 있습니다.

MVP

모델

・ Utility 와 같이 비즈니스 로직을 담당

View( View, ViewController )

・ MVC 에 처리를 의뢰( Presenter

Presenter

・ protocol 에 처리를 의뢰( Model 는 Presenter 에 의존)
· Model 의 정보를 취득하기 위해서 API등에 문의한다 ( Model 는 Controller 에 의존)
・ Utility 에 처리를 의뢰( output
반면에 protocol 에서 MVP 의 역할은 외부의 액션(Cell이나 Button 의 탭 등)을 Controller（View） 에 전달할 뿐입니다. 언뜻 보면 Presenter 와 Controller 사이에 종속성이 있는 것처럼 보이지만 Presenter 에서 관계를 갖게 하기 때문에 느슨하게 결합 상태입니다. 즉, 의뢰를 받은 Protocol 도 처리를 전하는 상대가 누구인지는 모릅니다. 이와 같이 프레젠테이션 로직이 분리되어 있기 때문에, 디자이너의 작업이 눌러져 있어도 작업을 진행할 수 있습니다.

끝에

이상입니다. 다음은 MVVM에 대해 정리하려고 생각합니다!