[Android] 디자인 패턴 (MVC, MVP, MVVM)

처음 안드로이드 개발을 시작할 때는 단순히 기능 구현에 집중을 했었지만 어느 순간부터 만드는 앱의 규모가 커지고 다양한 데이터를 다루다 보니 architecture에 대한 관심을 가지게 되었습니다. 그래서 찾아본 결과 Android에서 유명한 architecture에는 MVC, MVP, MVVM 이렇게 3가지가 있었습니다. 오늘은 이를 공부하고 정리해보려고 합니다.

 

아래의 글을 공부하며 내 나름대로 정리를 해보았습니다.

academy.realm.io/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/

MVC vs. MVP vs. MVVM on Android

MVC (Model View Controller)

아마 처음 안드로이드 개발을 접하다 보면 위의 구조를 가장 많이 접하게 될 것입니다. 나 또한 지금 MVC의 방법에 Manager를 구성해 데이터를 다루는 방식으로 개발을 해왔습니다.

 

위의 Architecture는 크게 이름에 나타나듯이 크게 3가지로 구성되어 있습니다.

 

• Model : Application의 두뇌라고 볼 수 있습니다. 데이터 + 상태 + 비즈니스 로직을 다룹니다. View나 Controller에 묶여 있지 않아 재사용이 가능합니다.
• View :  모델의 내용들을 표현해줍니다. 사용자가 application을 사용할 때 Controller와 통신합니다. 하지만 MVC에서 View는 모델에 대한 지식이 없고 사용자와 application이 상호작용을 할 때 수행하는 작업을 이해하지 못합니다. 
• Controlloer : Model과 View의 중간에서 데이터 변경이나 상호 작용을 관리하여 View나 Model을 업데이트시켜줍니다.

MVC 구조

하지만 이러한 구조는 Model 자체는 분리되어있기 때문에 단위 테스트가 가능하지만 Controller(Activity, Fragment)에 몇 가지 문제가 생기게 됩니다.

내가 느낀 가장 큰 문제점 2가지는 View의 변경에 따른 Controller 변경이 빈번하게 일어나야 되고 이는 개발자에게 있어서 매우 귀찮은 작업이고 규모가 커지게 되면 많은 코드가 Controller에서 담당하기 때문에 자칫 application이 깨질 수 있습니다. 특히 라이브하고 데이터 변경이 빈번한 application 일수록 치명적일 수 있습니다.

 

MVP (Model View Presenter)

이러한 MVC의 문제점을 해결하기 위해 나온 패턴인데 일단 Controller를 분리하여 Controller의 책임을 줄이고 View와 Activity/Fragment가 자연스럽게 결합되도록 만들었습니다. 

 

• Model : MVC의 model과 같은 역할을 합니다. 
• View : Activity/Fragment가 View의 일부분으로 간주됩니다. Activity가 View Interface를 implements 하여 이를 통해 특정 View에 결합하는 것을 제거하고 View의 모의 구현으로 단위 테스트가 가능해집니다.
• Presenter : MVC의 Controller의 역할이지만 View에 전혀 연결되어 있지 않은 인터페이스입니다. 이를 통해 모듈성, 유연성 문제뿐만 아니라 테스트 가능성 문제를 해결합니다. 

MVP 구조

MVC와 다른 점은 Controller에 Activity나 Fragment가 들어가는 대신 Presenter라는 Interface가 들어갔습니다. 기존의 Controller에 다루던 함수나 기능들이 Presenter라는 interface에 모여서 사용 시에는 interface 형식으로 가져와서 좀 더 유연성과 모듈화에 초점을 둔 것 같습니다.

 

그렇다고 단점이 없는 건 아닌 것 같습니다.  Presenter도 Controller와 마찬가지로 시간이 지남에 따라 추가 비즈니스 로직을 수집하는 경향이 있습니다. 결국 이는 Presenter의 몸집이 커져 유지보수 관리가 힘들 수 있다는 것을 의미하는 것 같습니다.

 

MVVM (Model View ViewModel)

Android 개발을 시작하고 익숙해지면 MVVM이란 말을 가장 많이 들어볼 것입니다. MVVM은 Data-binding을 사용하여 더 쉬운 테스트 및 모듈화의 이점을 동시에 제공하고 View + Model을 연결하기 위해 작성하는 Glue 코드 양을 줄여 줍니다.

 

흔히 말하는 객체지향 디자인 패턴의 옵져버 패턴을 본떠서 만든 구조 같습니다. "옵져버 패턴의 옵져버 역할은 ViewModel이라는 친구가 한다."라고 생각하면 쉽게 이해가 될 것입니다. 

 

• Model : MVC의 Model과 같습니다.
• View : 가변적인 방식으로 ViewModel에 의해 노출되는 관찰 가능한 변수 및 작업에 바인딩됩니다.
• ViewModel : Model을 wrapping 하고 View에 필요한 관찰 가능한 데이터를 준비합니다. 또한 뷰가 이벤트를 모델에 전달하기 위한 hooks를 제공합니다. 하지만 ViewModel은 뷰에 연결되어 있지 않습니다.

MVVM 구조

MVVM의 단점은 View과 변수나 표현식 모두에 바인딩할 수 있으므로 시간이 지남에 따라 외부 Presentation 논리가 유입되어 XML에 코드를 추가할 수 있습니다. 이는 단위 테스트에 영향을 줄 수 있기 때문에 이를 방지하려면 뷰 바인딩 표현식에서 값을 계산하거나 파생하지 말고 항상 ViewModel에서 직접 값을 가져와야 한다고 말하고 있습니다.

 

아래는 제가 만든 MVVM + Clean Architecture 예제입니다.

2022.11.02 - [개발/Android] - [Android] MVVM 패턴 및 Clean Architecture, Android Jetpack 적용 예제

[Android] MVVM 패턴 및 Clean Architecture, Android Jetpack 적용 예제

정리

MVP와 MVVM은 모두 앱을 모듈화하고  단일 책임 요소로 분할하는 데 MVC보다 더 나은 작업을 수행하지만 Application에 더 많은 복잡성을 추가됩니다. 오히려 앱이 간단하고 라이브 하지 않다면 MVC에서 더 잘 작동할 것입니다.

결국에 가장 중요하게 생각하는 건 구조에 얽매이지 말고 현재 개발하는 Application에 최적의 구조를 스스로 응용해서 만들 수 있어야 한다는 것입니다. 다음에는 MVVM, MVP에 대해 코드를 작성하면서 더 자세히 알아보겠습니다.