[디자인패턴] MVC, MVP, MVVM 에 대해 알아보자

앱 개발 도중, 앱의 개발효율을 높이기 위해 디자인패턴의 도입의 필요성이 느껴졌다.

많은 디자인패턴들이 있지만 가장 유명한 MVC, MVP, MVVM에 대해 알아보고자 한다.

디자인패턴을 한마디로 정리하자면, '역할을 독립적으로 나눈다'라고 할 수 있겠다.

---

1. MVC

Model + View + Controller

구조

• Model : 어플리케이션에서 사용되는 데이터
• View : 사용자에서 보여지는 UI
• Controller : 사용자의 입력(Action)을 받고 처리

동작

사용자의 action이 controller에 들어오면, controller는 model을 확인하고 그 model을 보여줄 view를 선택한다.

view는 model을 이용해 화면에 보여주게 된다.

 

단점

view와 model이 의존적이다. 

특히 안드로이드 앱에서는 뷰와 모델이 결합되어있는 경우가 많다고 한다.

이럴 경우 데이터 및 앱의 크기가 커지면 커질수록, 뷰와 모델 간의 의존성이 점점 커지고 복잡해진다는 단점이 생긴다.  

---

 

2. MVP

Model + View + Presenter

구조

• Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리
• View : 사용자에서 보여지는 UI
• Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달. View와 Model을 붙여주는 접착제 역할

동작

사용자의 action이 view를 통해 들어오면, view는 presenter에 데이터를 요청.

presenter는 model에 데이터를 요청하고 model은 이에 응답.

presenter는 model로부터 받은 데이터를 view에다가 응답.

view는 presenter로부터 받은 데이터를 활용해 화면에 보여준다.

 

장점

MVP는 앞서 MVC와 달리 View와 Model 간의 의존성이 없다는 점이 장점이다.

오직 Presenter를 사용해서 데이터를 주고받는다.

 

단점

대신 View와 Presenter간의 의존성이 높아졌다.

이 또한 앱이 커지면 커질 수록 둘 간 의존성이 점점 커진다.

---

 

3. MVVM

Model + View + View Model

구조

• Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리
• View : 사용자에서 보여지는 UI
• View Model : View를 표현하기 위해 만든 Model. View를 나타내기 위한 데이터 처리.

 

동작

사용자의 action이 view를 통해 들어오면, command 패턴으로 view model에 action을 전달.

view model은 model에 데이터를 요청하고, 응답받는다.

view model은 model로부터 받은 데이터를 가공 및 저장한다.

view는 view model과 data binding하여 화면에 나타낸다.

 

장점

MVVM 패턴은 Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현되었다.

Command 패턴과 Data Binding을 이용하여 View와 View Model 사이의 의존성을 없앴다.

 

단점

단, View Model의 설계가 쉽지 않다. ^^

---

주니어 개발자라고도 말 할 수 없는, 아마추어인 나는 아마 MVC로 먼저 시도해봐야할 듯 싶다.

MVP로 할까 어쩔까 고민 많이 하다가 어디선가 본 글에서 회사에서 만드는 프로그램도 아니고 작은 프로젝트 단위라면 MVC를 쓰는게 낫다는 의견을 봐서...

오히려 작은 프로젝트에서 더 광활한 디자인패턴을 쓸 수록, 쓸데없는 코드들이 늘어날 가능성이 있다고 한다. (?)