[아키텍쳐] MVP 란

오늘은 MVx 패턴 중 MVP 패턴에 대해 알아보려구 한다!!

전에 있던 팀에서 MVP 패턴을 사용하여 개발 중이었는데 이때 ViewController 말고 Presenter 파일을 하나 더 만들어 파일이 정말 많았었던 경험에 이어 MVP 패턴에 대해 정리하고자 한다.

 

MVP 패턴

Model, View, Presenter 3가지로 이루어진 패턴이다.

MVC 패턴과 다르게 Presenter의 개념을 가지고 있다. 

 

우리가 MVC 패턴을 활용해 개발을 하다보면 Controller가 View와 밀접하게 연관되어 View+Controller 의 꼴로 합하여 개발되는 경향이 있다. ViewController가 지닌  생명주기 역시 고려해야 하기 때문에 대규모 프로젝트에 있어 Controller가 더욱이 비대해진다. 

이런 문제점을 해결하기 위해 Controller 대신 Presenter 개념을 도입하였다.

즉 Presenter는 생명주기와 연관이 없고 오로지 뷰의 이벤트에 반응해 상태 변화를 알려주는 역할 + 뷰의 상태를 받아와서 모델에 업데이트 해주는 역할을  수행한다.

 

상호작용 하는 과정

1. View에 사용자의 이벤트가 들어온다.

 

2. View는 Presenter에게 이벤트를 알린다.

 

3. Presenter는 이벤트를 받아 로직을 수행한다. Model의 변화가 필요하다면  변화를 수행한다.

 

4. 변화를 View에 업데이트 한다.

 

이렇게 Presenter는 Model과 View 사이 중간자의 역할을 하며 로직을 수행하고 나중에 이 로직만 가지고 Unit Test하기 용이한 측면도 있다! 하지만 MVP 패턴 역시 View와 Presenter간 이벤트 수행이 많을 경우 의존 관계가 강해지는 경향이 있어 

MVC 패턴에서 문제시 되었던 View+Presenter가 비대해질수 있다.

 

예제

LoginViewController

안에 Presenter를 가진다.

 

LoginPresenter는

로그인 기능에서 수해될 기능들을 프로토콜로 명시해두고

 

View와 Model을 가지고 있어 이곳에서 업데이트 작업을 수행한다.

 

Presenter의 기능들을 프로토콜로 빼두었는데 이렇게 한다면 후에 Unit Test시 

LoginPresenter만을 선언해 필요 기능들을 수행하도록 할 수 있다.

 

앞서 얘기했던 Presenter과 View간의 의존 관계를 해결하기 위해 다음에 고안된 패턴이 바로 MVVM 패턴이라고 한다. 앞서 MVP 코드를 보면 View는 Presenter를 Presenter는 View를 참조하고 있다. 이는 View와 Presenter가 완전히 독립적이라고 할 수없을 것이다. 하지만 MVVM 패턴에서는 View가 ViewModel을 가지고 있으나 MVP에서 Presenter와 달리 ViewModel은 View를 가지고 있지 않다. 그렇다면 view를 모르면서 어떻게 업데이트 해줄 수 있는 것일까 ?

MVVM의 가장 강력한 특징 중 하나는 Data Binding이다. View에서 인풋 또는 아웃풋으로 들어오고 나가는 데이터들을 ViewModel과 바인딩하는 작업을 수행한다. 따라서 ViewModel은 View에서 받아온 데이터들을 활용해 모델을 업데이트 하고 이를 다시 view에 업데이트 할 수 있는 것이다. 그러므로 MVVM 패턴에서는 View 부분이 오로지 View만을 업데이트 하는데 코드 책임 분리를 명확히 할 수 있다. 자세한 내용은 MVVM에 대해 정리 한 글이 있으니 참고하길 바란다 !! 

 

이렇게 MVC ~ MVP ~ MVVM  패턴을 각각 알아보았다. 순서는 뒤죽박죽이었지만 MVVM 패턴으로 작성한 코드 중 ViewModel에 View의 일을 주입해준 위반(?) 이 생각나서 고치러 가야 할듯하다 !!