[Android] MVC vs. MVP vs. MVVM

MVC (Model,View,Controller)

MVC 패턴은 Controller가 사용자로부터 Action을 받아, Model에게 전달하고 모델이 해당 Action에 대한 처리를 마친 뒤에 View적용하는 방식입니다.

Model과 View 사이의 의존성이 높고, Controller가 안드로이드 API에 깊게 종속되므로 유닛 테스트가 어렵다는 단점이 있습니다.

모델(Model)

• 앱의 두뇌 역할을 합니다.
• 데이터, 상태, 비즈니스 로직을 처리합니다.
• 뷰나 컨트롤러에 묶이지 않습니다.

뷰(View)

• 모델의 표현 입니다.
• UI를 그리고 사용자가 앱과 상호작용할 때 컨트롤러와 통신하는 책임을 맡습니다.
• 뷰는 하위 모델에 대한 지식이나 상태에 대한 이해가 없고, 사용자가 버튼을 클릭하거나 값을 입력하는 등의 행동을 할 때 무엇을 해야 하는지 모릅니다.
• 뷰가 덜 알수록 모델에 종속되지 않으므로 보다 변화에 유연합니다.

컨트롤러(Controller)

• 앱을 묶어주는 역할입니다.
• 모든 입력을 처리하는 곳 입니다.
• 입력에 따라 모델에서 데이터를 처리하여 뷰를 보여줍니다.

 

MVP (Model,View,Presenter)

View가 User에게 Action을 입력받으면, Presenter를 통해 Model에 데이터를 요청하고, 해당 데이터를 통해 View를 Update하게 됩니다.

MVP는 View와 Model은 의존성이 없는 대신, View와 Presenter가 1:1로 강한 의존성을 가지게 됩니다. MVC와 MVP는 시간이 지나면 지날 수록 Presenter와 Controller에 비즈니스 로직이 집중되는 경향이 있습니다. 따라서 유지보수에 좋은 방식은 아닙니다.

모델(Model)

• 앱의 두뇌 역할을 합니다.
• 데이터, 상태, 비즈니스 로직을 처리합니다.
• 뷰나 프레젠터에 묶이지 않습니다.

뷰(View)

• UI를 담당합니다. 안드로이드에서는 Activity, Fragment가 대표적입니다.
• 모델에서 처리된 데이터를 프레젠터를 통해 받아서 유저에게 보여줍니다.
• 유저 동작(Action)을 프레젠터에 보내는 역할을 합니다.
• 프레젠터를 이용해 데이터를 주고받기 때문에 프레젠터에 매우 의존적입니다.

프레젠터(Presenter)

• 뷰와 모델의 매개체입니다.
• 모델과 뷰를 매개체라는 점에서 MVC의 컨트롤러와 유사하지만, 뷰에 직접 연결되는 대신 인터페이스를 통해 상호작용 한다는 점이 다릅니다.
• 뷰에게 표시할 내용만 전달하며 어떻게 보여줄지는 뷰가 담당합니다.

 

MVVM (Model,View,ViewModel)

MVVM은 하나의 소프트웨어를 최대한 기능적으로 작은 단위로 나누어 테스트가 쉽고 큰 프로젝트도 상대적으로 관리하기가 좋은 구조입니다.

Android에서 LiveData,DataBinding과 함께 사용됩니다.

모든 입력(Input)들은 View로 전달되며 ViewModel은 입력에 해당하는 Presentation Logic을 처리하여 View에 데이터를 전달합니다. ViewModel은 View를 따로 참조하지 않기 때문에 독립적이며 ViewModel과 View는 1:n의 관계를 가질 수 있습니다.

모델(Model)

• 비즈니스 로직과 유효성 검사와 데이터를 포함하는 앱의 도메인 모델로 생각할 수 있습니다.
• 앱에서 사용할 데이터에 관련된 행위와 데이터를 다룹니다.

뷰(View)

• Activity나 Fragment 같은 화면에 표현되는 레이아웃을 정의함.
• 기본적으로 데이터를 보여주기만 해야하지만 UI 변경과 관련된 일부 로직은 포함될 수 있습니다.
• ViewModel을 관찰하고 있다가 상태 변화가 전달되면 화면을 갱신합니다.

뷰 모델(ViewModel)

• 뷰와 모델의 매개체입니다.
• 모델에서 제공받은 데이터를 UI에서 필요한 정보로 가공한 뒤 뷰가 가져갈 수 있게 데이터 변경에 대한 "이벤트"를 보냅니다.
• 뷰 모델과 뷰는 Many to One의 관계를 가질 수 있습니다. 즉, 여러개의 뷰가 하나의 뷰 모델을 가질 수 있습니다.
• 뷰 모델은 뷰에 영향을 끼칠 수 있는 모델의 상태 관리도 담당합니다.
• 뷰의 Context에 대한 정보를 가지면 안됩니다. 뷰는 뷰 모델의 래퍼런스를 가지지만 뷰 모델은 뷰에 대한 정보가 전혀 없어야 합니다. 만약 가지게 된다면 lifecycle에 메모리누수가 발생할 수 있습니다. 그 이유는 뷰 모델이 destroy 상태에서만 메모리에서 해제되기 때문입니다.