서론

지금까지 안드로이드 개발을 하면서 아키텍처 패턴을 적용해서 개발을 해본 적이 없다. MVC, MVP, MVVM이 잘 알려져 있는데, 굳이 이 범주에 포함시켜 보자면 MVC로 개발을 진행했던 것 같다. 이번에 부스트캠프를 하는데, 어떤 교육을 받는 과정이 아니라 실무 프로젝트 중심으로 진행한다고 한다. 그래서 내가 배워보고 싶은 것들은 내가 노력하고 시간을 투자해서 공부하고 배워야 할 것 같다. 그 과정에서 어려운 것이 있다면 멘토님들한테 질문을 해보자.

안드로드에서 테스트 코드를 작성하기 위한 방법 중 하나로 MVP를 선택해서 사용한다고 한다. 또한 Model, View, Presenter 간의 상호 의존성을 떨어트리기 위한 용도도 있다고 한다.

MVP란?

서론이 조금 길었다. 그렇다면 MVP란 무엇일까?
MVP를 알기 위해서는 MVP의 각 단어의 역할과 목적이 중요하다.

  • Model : Data와 관련된 처리를 담당
    • Data의 전반적인 부분을 model에서 담당하고, 네트워크, 로컬 데이터 등을 포함한다.
  • View : 사용자의 실질적인 이벤트가 발생하고, 이를 처리 담당자인 Presenter로 전달한다.
    • 완전한 View의 형태를 가지도록 설계한다. 계산을 하거나 데이터를 가져오는 등의 행위는 Presenter에서 처리하도록 한다.
  • Presenter : View에서 전달받은 이벤트를 처리하고, 이를 다시 View에 전달한다.
    • View와는 무관한 Data등을 가지고, 이를 가공하고 View에 다시 전달하는 역할
MVP 구조

MVP의 기본 패턴

MVP를 처음 접해보고 이제 시작하는 나로서는 그냥 빙글 빙글 돌려놓은 듯한 느낌을 받았다. 이를 아래와 같은 그림처럼 표현할 수 있다.

이를 순서대로 나열하면 아래와 같다.

  1. View : View에서 터치 이벤트 발생
  2. View -> Presenter : Presenter로 이벤트 전달
  3. Presenter : View에서 요청한 이벤트 처리
  4. Presenter -> View : 처리한 결과를 View로 전달
  5. View : 처리된 결과를 바탕으로 UI를 갱신

위와 같은 형태를 가지며 1~5번까지 처리가 완료되면 이후 같은 동작이 계속적으로 일어난다. 일반 코드라면 하나의 액티비티 파일 안에서 모두 처리가되니까 눈으로 보긴 편하다. 따라갈 필요도 없고, 함수만 따라다니면 보기도 쉽기 때문이다. 그래서 MVP를 빙글 빙글 돌려놓은 것 아닐까? 라는 답이 나올 수 밖에 없다.

MVP에 모델을 더하면?

위에서 기본적으로 작성한 MVP에 모델을 더하면 아래와 같이 표현이 가능하다.

  1. View : View에서 터치 이벤트 발생
  2. View -> Presenter : Presenter에 이벤트 전달
  3. Presenter : 이벤트의 형태에 따라 캐시 데이터를 가져오거나 Model에 요청
  4. Presenter -> Model : Presenter에서 데이터를 요청 받음
  5. Model : 데이터를 로컬 또는 서버에서 가져온다.
  6. Presenter : 전달 받은 데이터를 가공
  7. Presenter -> View : 가공한 데이터를 View에 전달
  8. Vie : Presenter로부터 전달받은 데이터를 View에 갱신

상황에 따라서 Presenter는 Model을 사용할 수도 사용하지 않을 수도 있지만 기본 형태는 위와 같다.

참고