안드로이드 MVC, MVP Pattern

Kotlin에 대해서 공부를 하면서 MVC와 MVP 패턴에 대해서 생각해 볼 수 있는 기회가 생겼고 정리하고자 글을 포스팅 한다.

MVC 

MVC 모델은 Spring MVC를 통해서 가장 많이 접했던 구조라 말할 수 있다.

Model , View, Controller 세가지로 나누어 정의 한다.

 

Model은 View나 Controller에서 독립되어 Object(Data)의 상태나 비지니스 로직을 담당하게 됩니다. Controller에서는 View에 모델을 통해서 정보를 전달하게 된다.

View는 사용자와의 인터렉션을 하는 영역으로 UI를 그리고 컨트롤러와 통신을 하는 역할을 맡습니다. View는 모델이나 컨트롤러와는 독립적으로 순전히 View 본연의 역할만을 수행하는 것이 좋습니다.

Controller는 Model과 View 를 묶어주는 역할을 합니다. View에서 컨트롤러로 어떠한 요청을 보내고 컨트롤러에서는 요청에 대한 처리를 진행합니다. 이때 모델에 변경이 생겼고 다시 View의 갱신이 필요한경우 컨트롤러는 다시 View에 변경된 모델을 내용을 알려주게 됩니다.

위 설명은 일반적인 MVC 패턴의 구성요소별 설명이라고 생각하면 된다.

반면에 안드로이드에서는 View 와 Controller 의 영역에 대한 구분히 모호합니다. 이와 관련된 역할을 하는것은 Activity 나 Fragment가 담당하게 되는데, 프로젝트를 진행을 하다보면 의식적으로 모델과 관련되어 있는 부분은 Repository로 분리해서 데이터를 다루게 되지만 View와 Controller 는 Activity나 Fragment에서 별도 구분없이 프로그래밍을 하게 된다.. 이러한 작업이 연속으로 이루어지다 보면  거대한 Activity나 Fragment를 만나게 됩니다. 거대한 Activity나 Fragment는 그만큼 거대한 테스트클래스가 필요하다는걸 말한다.  또한 View와 Controller의 역할을 하나의 클래스에서 하게되다보면 View 영역의 변경이 Controller에 미치게되고 그 반대또한 가능하게 된다. 그만큼 유지보수 비용이 많이 발생하게 된다.

이러 문제들을 해결하고자 MVP 모델을 사용한다.

MVP

MVC 모델에서 Model의 역할은 MVC 패턴과 같이 데이터를 저장하고 핸들링하는 부분을 담당한다.

다른점은 View 의 영역을 보다 명확히 하여. Activity 나 Fragment가 View의 일부로서 동작한다는 점이다. 엑티비티는 뷰 인터페이스를 구현하고 Presenter가 인터페이슬 가지고있게 만들어 특정한 뷰에 결합되지 않은 상태에서 가상의 View 를 통해서 독립된 유닛 테스트를 실행할 수 있게 된다.

Presenter는 인터페이스로서 MVC가 가지고있는 테스트의 어려움을 극복하고 모듈화/유연성 문제 또한 해결합니다. 명심해야 할 부분은 Presenter는 인터페이스로 종속성이 발생해서는 안되며 유스케이스를 구현하게 된다.