[웹키워드#4] MVC, MVP, MVVM

중, 고등학교 미술 시간 그림을 그릴 때 우리는 '구도'에 대해 배웠고, 이를 활용하여 그림을 그렸던 기억이있다. 컴퓨터 프로그램을 만들 때도 '구도', 전문용어로 '디자인 패턴'이 중요하다. 디자인 패턴은 건축으로 치면 공법에 해당하는 것으로 소프트웨어의 개발 방법을 공식화 한 것이다. 소수의 뛰어난 엔지니어가 해결한 문제를 다수의 엔지니어들이 처리할 수 있도록 한 규칙이면서, 구현자들 간의 커뮤니케이션의 효율성을 높이는 기법이다.  (위키피디아 참고)

웹 서비스를 디자인하는데 자주 사용되는 여러 디자인 패턴들이 있다. 자주 사용되는 만큼 검증된 내용들이고, 웹 서비스를 효율적으로 운영하는 것을 도와준다. 오늘은 그 디자인 패턴들에 대해 알아보고자 한다. (Model과 View를 어떻게 연결 지으냐에 따라 각 패턴이 나뉘게 된다.)

MVC (Model View Controller)

오늘날 웹 프레임워크의 시발점이다. MVC 모델이란, 하나의 웹 애플리케이션을 Model, View, Controller라는 세 가지 요소로 나누어 각각에 대하여 고유한 역할을 부여하는 일종의 설계 패턴이다. 쉽게 말하면 각 분야별로 일을 분업하여 전담하는 주체라고 할 수 있다. 

MVC 모델을 잘 이해하는 것이 웹 개발자에게는 대단히 중요하다. 특히 Model과 View는 MVC 외에도 사용되는 개념이니 유의해서 알도록 하자. 

- Model (모델)

Model은 데이터를 다루는 요소이다. Mysql, MongoDB와 같은 DBMS(Database Management System)를 통해 데이터베이스 상에서 새로운 테이블을 만들고, 저장하고, 수정하는 등 데이터를 다루는 거의 모든 작업을 담당한다. 

- View (뷰)

View는 웹 서비스 사용자들에게 직접적으로 보여지는 부분을 다루는 요소이다. 클라이언트가 브라우저 상에서 볼 수 있는 부분들, 즉 외관을 구성하는 요소들을 아우른다. 키워드 첫 부분에 설명한 웹 페이지 표현 요소들인 HTML, CSS, JavaScript 등의 파일들이 이에 속한다. 

- Controller (컨트롤러)

Controller는 Model과 View 중간에서 둘 간의 상호작용을 중재하는 요소이다. 쉽게 말하면 Model이 관리하는 DB에 저장된 데이터들을, 웹 브라우저 즉, View 창에 띄워주는 역할을 한다. 

즉, Controller는 클라이언트의 URL 요청을 받아(입력을 담당한다) 웹페에지를 보여주고자 하는데, 그 과정에서 필요한 데이터를 얻기 위해 Model에게 데이터를 요청하고, Model이 DBMS를 조작하여 해당 데이터를 찾아와 Controller로 전달해주면, Controller는 이 데이터를 해당 웹페이지의 View에 반영한 뒤 클라이언트 측으로 제공하는 것이다. 

(출처: http://coding-dragon.tistory.com/4)

위 그림과 같이 모든 입력은 Controller가 받아서 처리한다. 입력이 들어오면 Controller는 입력에 해당하는 Model을 업데이트하고, Model을 표현해 줄 View를 선택한다. 하나의 Controller는 여러개의 View를 가질 수 있으며, Controller는 여러개의 View를 선택하여 Model을 표형할 수 있다. 반대로 View는 Controller에서 어떤 동작이 일어나는지 알수 없다. 

이때 Controller는 View를 선택할 뿐 직접 업데이트 하지 않기 떄문에, 주로 다음과 같은 방법을 통해 View를 업데이트 한다. 

• View가 Model을 직접 사용하여 업데이트

• Model에서 View에게 Notify해 주는 방법

• View에서 Polling하여 Model의 변화를 받아오는 방법

결국 View 화면을 업데이트하기 위해 Model을 직/간접적으로 참조하기 때문에 서로간의 의존성을 완전히 없앨 수 없다. '중매 아줌마'를 연상시켜보자. '중매 아줌마'는 남/녀를 선택하여 소개만 시켜줄 뿐, 서로가 서로에 대해 직접 알아가야한다. 즉, MVC 또한 Controller는 소개만 시켜줄 뿐 Model과 View가 직접 알아가야하는 부분이 있다. 이에, MVC 패턴을 사용할 경우 View와 Model간 의존성을 최소화 시키는게 좋은 구성이다. 

참고

- 코드라이언 (http://www.codelion.net)

- http://coding-dragon.tistory.com/4

- http://blog.javarouka.me/2013/06/understanding-mvc-mvp-and-mvvm.html

MVP (Model View Presenter)

MVP 모델은 MVC 모델의 단점을 보완하고자 파생된 모델이다. Model, View의 개념은 기존 MVC 모델과 같다. 하지만 MVC 모델의 한계였던 Model과 View의 의존성을 없애기 위해, Controller 대신 Presenter를 사용한다. 

(출처: http://coding-dragon.tistory.com/4)

Presenter는 Model과 View의 상호작용을 담당한다. Client에서 들어오는 입력은 MVC와 다르게 View가 받아 처리하며, 이벤트가 들어왔을 때 View는 이벤트를 Presenter에 전달한다. Presenter는 이벤트를 바탕으로 Model을 조작하고, 이를 바탕으로 View에 바인딩하면 각 요소들이 업데이트 되는 구조이다. 

View는 Presenter와 1:1 관계로 이루어진다. MVC에서 Controller는 View를 선택하고 Model을 조작하는 역할만 수행하고, 실제 화면 갱신은 Model과 View의 상호작용으로 이루어졌다. 하지만 MVP 모델에서는 Presenter가 Model과 View중간에서 상호작용을 관리하며 실제 화면 갱신 작업을 담당한다. 

즉, Presenter는 View와 그에 해당하는 Model의 인스턴스를 가지고, Model과 View 사이의 매핑을 전적으로 담당하는 구조이다. 이때 Model은 Presenter의 요청에 의한 처리만 수행하면 되므로 다른 요소와의 상호 작용에 대해 신경쓸 필요가 없다. 

Model과 View의 의존성은 MVC와 달리 사라졌지만. 여전히 Presenter와 View 간의 1:1관계로 인한 둘의 의존성이 매우 강해진다는 이슈가 있다. 

참고 및 인용

http://coding-dragon.tistory.com/4

MVVM (Model View ViewModel)

이 역시 MVC 모델에서 파생되었으며, Model과 View 사이으이 의존성 뿐 아니라 View와 Controller 사이의 의존성도 고려하여 각 요소가 완전히 독립적일 수 있도록 설계된 패턴이다. 

(출처: http://coding-dragon.tistory.com/4)

MVP에서 Presenter와 View가 의존 관계에 있었다면, MVVM에서 View와 ViewModel은 독립적인 관계를 형성한다. MVP와 마찬가지고 View는 Client로부터 입력을 받고, ViewModel은 Presentation logic을 처리하여 View에 데이터를 전달하는 역할을 한다. 

각각의 View는 자신이 사용할 ViewModel을 선택하며, ViewModel은 Model을 베이스로 Presentation Logic에 따라 서로 다르게 구현된다. 따라서 View에 어떤 ViewModel을 연결하느냐에 따라 로직 처리가 달라지고, 각 로직 처링 따라 Model이 변경되면 해당하는 ViewModel을 사용하는 View가 자동으로 업데이트된다. 

결론

- 웹 디자인 프레임워크 사용의 장점

• 재사용 및 유지/보수에 용이하다. 
• HTML을 직접 다룰 수 있어 반응형 웹과 모바일 디바이스 지원 측면에서 좋은 전략을 세울 수 있다. 
• 분업에 용이하다. 
• URL 라우팅이 유용하고, 어떻게 구성하고 해석할지 쉽게 정할 수 있다. 
• 시스템에 다른 부분을 변경하지 않으면서 UI를 쉽게 변경할 수 있다. 
• 현재 사용하는 DB를 다른 환경으로 옮길지라도 룰에는 영향이 없다. 
• 각 요소가 서로 독립적이다. 

그렇다면 위 3가지 모델 중 어떤 모델을 사용하는 것이 가장 좋을까? 어떤 모델을 사용하면 조금 더 깔끔한 구조로 코드를 작성하고 쉽게 테스트 할 수 있을까? 

정답은 없다. 현재 개발하고 있는 프로그램 규모에 따라 오버 펙이 되지 않도록 적절한 모델을 찾아 적용하는 것이 필요하다.