안드로이드 아키텍처: MVP

MVP 패턴이란?

MVP 패턴은 앱의 구성 요소를 Model, View, Presenter로 나눈 아키텍처를 말한다.

이전 포스팅에서 MVC는 Controller가 Model의 데이터를 View로 직접 전달하지 못하고, View가 직접 Model에 데이터를 요청해야 한다는 단점이 있었는데, 이를 개선한 것이 MVP이다. MVP 패턴의 Presenter는 View와 Model 사이에서 Controller보다 좀 더 나은 중재자 역할을 수행한다.

 

MVP architecture

 

위 그림과 같이 Presenter는 View에서 요청한 입력에 대한 결과를 Model로 부터 가져와 다시 View에 전달해 줌으로써 View와 Model의 의존 관계를 제거하고, View는 오로지 Presenter가 전달해 준 데이터를 어떻게 표시할지에 대해서만 다룰 수 있게 된다.

안드로이드에서의 MVP 패턴

아래는 이해를 돕기 위해 EditText에 검색어를 입력하고 Button을 누르면 해당 검색어로 검색한 결과를 출력해주는 안드로이드 앱이 있다고 가정하고 Model, View, Controller에서 하는 역할을 간단한 코드로 작성한 결과이다.

View

// 사용자 입력 Presenter로 전달
button.setOnClickListener({
    presenter.findAddress(editText.text.toString())
    controller.findAddress(editText.text.toString())
})

Presenter

fun findAddress(address: String) {
    model.fetchAddress(address)
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(
            onStart = {
                view.showProgress()
            },
            onSuccess = { entityList ->
                view.hideProgress()
                view.updateList(entityList)
            },
            onError = { e ->
                view.hideProgress()
                view.showErrorMessage(e.message)
            }
        )
        .addTo(disposable)
}

Model

fun fetchAddress(address: String): Single<List<Entity>> {
    return getRetrofit().fetchAddressFromServer(address)
}

MVC 패턴과 비교하여 동일한 동작을 MVP로 구현했을 때, 아래와 같은 이점이 있음을 확인할 수 있다.

• View가 Presenter에만 의존적이다.
  MVC에서는 View가 Controller와 Model을 모두 알고있어야 했다.
• Model의 역할이 줄어들었다.
  Model은 API를 호출하고 데이터를 반환하는 역할만 한다.
  UI 로직, 스레드 관련 로직들은 모두 Presenter에서 다룬다.

MVP 패턴의 장단점

장점: 테스트, 모듈화를 쉽게 할 수 있다.

단점: 많은 양의 보일러플레이트 코드가 생긴다. (View의 생명주기에 따른 네트워크 요청 취소 처리 등..)