안드로이드에서의 MVC
MVC란?
소프트웨어 디자인 패턴 중 하나로 Model - View - Controller 를 의미한다. MVC는 비즈니스 로직과 화면을 구분하는데 중점을 두고 있고, 이러한 관심사 분리는 더 나은 업무의 분리와 향상된 관리를 제공한다.
- 모델: 데이터와 비즈니스 로직 관리
- 뷰: 화면, 사용자 입력, 응답 -> 화면에서 볼 수 있는 모든 것
- 컨트롤러: 뷰에서 받은 사용자 이벤트를 응답하여 모델 및 뷰에 이벤트 처리 요청
MVC에서 중요한 것은 관심사 분리이다. 모델과 뷰는 서로 직접적으로 통신해선 안 된다.
보통의 MVC는 데이터 상태가 변경되면 모델을 뷰에게 알려 어떻게 보일지 판단한다. 그러나, 내가 생각하는 안드로이드에서의 MVC는 Controller & View가 같이 존재하기 때문에 Model이 굳이 어떤 뷰에 보일지 어떻게 보일지 판단할 필요가 없어진다. 단순히 컨트롤러에 로직이 많아져 비대해지는 문제와 관심사 집중이 발생한다 생각한다.
MVC 장점
- 코드를 클래스로 분리하면 설계에 도움이 되고 개별적인 변수와 함수 대신 클래스 관점으로 생각할 수 있기 때문에 코드 전체를 이해하기 쉬워진다.
- 이같이 모델 - 뷰 - 컨트롤러 계층으로 분리하면 클래스 분리와 마찬가지로 각 계층의 관점으로 생각할 수 있기 때문에 애플리케이션을 설계하고 이해하는 데 도움이 된다.
- 또, MVC는 클래스를 재사용하기 쉽도록 해준다.
여러 일을 혼자서 처리하는 클래스보다는 제한된 책임을 갖는 클래스를 재사용 하는 것이 더 쉽기 때문
MVC 단점
- 다양한 기능을 제공하는 규모가 큰 앱에서는 컨트롤러 계층이 커지거나 복잡해질 수 있다.
컨트롤러에서 필요한 기능을 수행하기 위해 비즈니스 로직 제어, 뷰 제어를 함께하기 때문에 컨트롤러의 코드가 비대해질뿐더러 이러한 비대해진 컨트롤러는 테스트하기 어려워진다.
- 뷰와 모델의 결합도가 상승한다.
뷰에서 직접적으로 모델을 호출해 데이터 갱신과 같은 작업을 하기 때문
안드로이드에서의 컨트롤러는 뭘까? 안드로이드에는 기본적으로 Activity, Fragment가 존재한다. 사용자는 앱을 처음 실행하면 액티비티를 맞이하게 되고, 그 액티비티 내부는 프래그먼트가 있을 수도, 액티비티만 존재할 수도 있다. 우리는 보통 이렇게 화면에 보이는 것들을 View 라고 칭한다. 그런데 안드로이드에서는 해당 View들의 응답, 이벤트를 작성하게 되어 컨트롤러와 뷰가 같이 공존하게 된다. 그럼 이건 온전히 뷰라고 칭할 수 있을까?
그래서 안드로이드에서의 뷰, 컨트롤러는 Activity, Fragment가 된다. 기능이 많아진다는 것은 Activity, Fragment 내에 코드가 많아지고, 이로인해 유지보수, 테스트가 어려워진다.
정리
이러한 MVC의 단점을 보완하고자 나온 것이 MVP(Model - View - Presenter) 이다. 간략하게 설명하자면 뷰는 Presenter와 소통하고, Presenter는 view에서 받은 메시지를 통해 Model에 비즈니스 로직을 수행하고, 그 결과를 View에 Update하는 작업을 수행한다. 이렇게 하면 애매한 Activity의 역할, 책임을 Presenter에게 줘서 코드를 줄일 수 있고, 유지보수 하기 편리해지며 테스트를 작성하기 용이해진다.
그럼, MVP는 만능인가?
그렇지 않다. 이와 관련해서는 다음에 다시 알아보도록 하자.
