[Android] 안드로이드 아키텍처 (2) — MVC
지난 포스트에는 안드로이드 아키텍처(MVC, MVP, MVVM)의 Model과 View에 대해 알아보았다.
이번 포스트는 많이 알려진 MVC 패턴에 대한 것이다. 안드로이드를 처음 시작할 때에도 이 패턴을 이용해 시작하는 경우가 대부분일 것이라 생각한다.
MVC Pattern
MVC패턴은 안드로이드 뿐만 아니라 다양한 프로그래밍에서 사용되고 있는 패턴이다. Model — View — Controller의 줄임말이다. 아래 이미지는 MVC의 구조와 역할에 대한 것이다. Model과 View에 대해서는 이전 포스트에서 설명했기에 여기서는 간단하게 흐름만 이야기할 것이다.
Model
- 데이터 + 상태 + 로직으로 이루어진 Layer.
- 재사용성 (View와 Controller에 묶이지 않음)
View
- 사용자에게 실제 보일 화면
- UI 업데이트와 관련해 Controller와 소통
Controller
- 사용자 입력을 받는다
- Model에게 데이터 변화를 알린 후 이에 따라 View와 소통
즉, Controller는 사용자 입력을 받아서 Model에게 데이터 업데이트 여부를 확인하고 이에 따라 View의 UI를 업데이트를 할지 말지 정하게 된다.
아래 코드를 통해 쉽게 이해할 수 있다.
Controller는 Model과 View를 가지고 소통하게 된다. 비교적 간단하다.
안드로이드에서 MVC는 어떻게 구현될까? 안드로이드는 같으면서도 조금 다른 애매모호한 MVC패턴의 형태를 가지고 있습니다. 아래와 코드와 같이 Activity나 Fragment가 뷰와 컨트롤러의 역할을 둘 다 가지고 있기 때문이다.
Activity에서 사용자 입력(버튼 클릭)에 따라 모델에게 데이터 업데이트(입력받은 EditText Text)를 요청하고 이에 따라 UI( Text)를 업데이트한다. Activity가 Controller와 View의 역할을 같이하게 되는 것을 알 수 있다.
보통 처음 안드로이드 개발을 할 때 이렇게 코드를 짜게 된다. 로직이 적고 코드가 적다면 괜찮은 패턴이라고 생각한다. 하지만 복잡한 로직이 많아지고 기능이 많아진다면 View와 Controller기능을 모두 담당하는 액티비티나 프래그먼트의 코드가 많아져 알아보기 힘들어질 것이다.
이런 구조의 코드들을 더 유지보수하기 쉽고 의존성은 적게, 알아보기 쉽게 만들기 위해 다른 패턴들이 생겨나고 적용되고 있다고 생각한다. MVP나 MVVM도 그 중 하나라고 생각한다.
안드로이드 개발을 해오며 느낀 MVC패턴에 대한 장점과 단점은
장점
- 개발속도가 빠르다. (Activity나 Fragment 하나에서 많은 코드가 있어 분리를 하지 않는다)
- Model과 View의 상호 의존성이 줄어들었다.
- 구현하기 쉽다.
- Model 재사용 가능
단점
- 조금만 코드가 길어져도 스파게티 코드가 되기 쉽다.
- 협업에 있어서 코드의 파악과 유지보수가 어려워진다.
- Model과 View의 의존성이 완전히 없어지지 않는다.
다음 포스트에서는 MVP에 대해 알아볼 것이다.
