MVP 패턴에 대하여

MVC 패턴에 대한 실증

 

 Apple에서 기본적으로 제공하는 패턴인 MVC 디자인패턴은 입문자 또는 규모가 크지 않은 프로젝트에서 주로 사용되는 디자인패턴이라고 생각합니다.

저 또한 회사에서 혼자 개발을 해야하고 규모가 크지 않은 프로젝트를 수행할 때 사용해왔습니다.

그러나 완성된 Product를 보고 나니 장점보다 단점이 더 부각되어 보였습니다. 

단점들은 Massive ViewController , 빈번한 Side Effect , 현저히 떨어지는 코드의 가독성 , 유지보수의 어려움이 있었습니다. 

이러한 단점들을 보완하고자 새로운 디자인 아키텍처를 찾는 도중 MVP 패턴을 찾았으며 이제부터 이에 대해 이야기를 해보려고 합니다. 

 

MVC 문제점

책임 분배의 부족

컨트롤러에서  작업 사용자 인터랙션 핸들링 , view 구성 , 네트워크 호출 작업 등 이러한 작업들이 모두 이루어집니다 

이로써 잘 알려진 Massive ViewController가 탄생하게 됩니다.

 

낮은 테스트 용이성

Massive ViewController가 탄생되며 단일 책임 원칙이 깨지게 됩니다.

모든 로직들이 View의 lifecycle과 연결되어 있어 각 단위의 테스트를 하기는 쉽지가 않습니다.

 

 

MVP 패턴이란

 

우선  MVP에 대해서 찾아보았다. 

 

View :  View 와 ViewController , UI setup 과 events 들로 구성된다.
Presenter: delegate를 통하여 모든 이벤트에 대한 책임과 UI 업데이트에 관한 책임을 갖는다. 

                     가장 중요한 점은 UIKit에 의존하지 않는점이다.

Model : 비지니스 로직 처리 및 Data access layer를 담당한다. 

 

요약

 1 .  view는 UI 구성 및 모든 이벤트들을 등록한다.

 2.  view에 모든 이벤트가 발생할 경우 presenter에 요청

 3.  presenter는 model에 요청 후 escaping closure를 통하여 결과를 전달 받는다 

 4.  presenrer는 전달받은 결과를 view에게 delegate로 전달한다. 

 5.  view는 전달받은 결과를 u 업데이트 역할을 담당한다.

 

 

간단한 MVP 패턴 예제 코드

 

View

 

Presenter

 

Model

 

프로젝트 구조

 

 

 

 

 

 

 

 

 

프로젝트 결과

 

 

읽어주셔서 감사합니다.