MVC, MVP, MVVM 무엇인가? :: 마이구미

이 글은 디자인 패턴 중 MVC, MVP, MVVM 패턴을 다룬다.

현재 프론트엔드, 백엔드, 앱 개발에서 많이 들리는 용어이다.

다른 패턴도 있지만, 현재 주로 사용하고, 알려져있는 패턴이라고 볼 수 있다.

MVC => Model - View - Controller

MVP => Model - View - Presenter

MVVM => Model - View - ViewModel

MVC 패턴은 크게 Model-View-Controller 3가지로 나눈 소프트웨어 개발 방법론이다.

현재에는 프레임워크 자체에 적용되어있어, 자연스럽게 접할 수 있고, 접하고 있을 것이다.

웹, 앱 개발시 많이 사용되고 있어, 다음과 같이 표현하기도 한다.

사용자가 Controller 를 조작하면, Controller 는 Model 을 통해 가져온 데이터를, View 에게 전달한다.

View 는 웹 사이트, Controller 는 서버, Model 은 데이터베이스라고 생각할 수도 있다.

이 글은 웹 또는 앱 환경이 아닌 조금 더 전체적인 측면에서 다뤄볼 예정이다.

MVP 와 MVVM 은 MVC 에서 파생되었다.

그렇다는 의미는 MVC 를 먼저 이해하는 것이 많은 도움이 된다.

MVC 를 먼저 다룬 후, 세가지의 패턴을 비교해보도록 하겠다.

MVC 의 Model-View-Controller 관계는 크게 Observer, Composite, Strategy 패턴으로 표현할 수도 있다.

* (위 그림의 선들을 보면, 점선과 선으로 표현되는 모습을 볼 수 있다. 선은 접근할 수 있는 여부라고 생각하면 된다.)

Controller 는 Model 에게 직접 말할 수 있다.

하지만 Model 은 Controller, View 에게 직접 말하지 않고, 변화 같은 경우에는 브로드캐스트와 같은 방식으로 알린다.

예로 옵저버 패턴을 들 수 있다.

Model 은 누구에게도 의존하지 않고, 독립적인 모습을 볼 수 있다.

Controller 는 View 와 직접 말할 수 있지만, View 는 Controller 와 직접 말하지 않는다.

또한 Controller 는 View 의 대리인(delegator)이다.

이에 따라 Controller 는 원하는 View 를 선택한다. 

유추할 수 있는 것은 일대다 관계와 View 는 Controller 의 존재를 모른다는 것이다.

예로 전략 패턴을 들 수 있다.

사용자 인터페이스는 수 많은 컴포넌트(버튼, 윈도우, 텍스트, 등) 으로 이루어져있다.

View 들을 중첩하여 내부적인 컴포지트 패턴을 통해 관리될 수 있다.

결론적으로 MVC 는 Controller 를 통해 관계를 느슨하게 만들어준다.

• 사용자 입력은 Controller 에 들어와 시각적 요소 변경없이 사용자 입력에 의해 View 가 변경되는 방식(View-Controller 느슨한 결합)
• Model 에 연관되는 여러 개의 View 는 서로 다른 방식의 표현을 제공할 수 있다.(View-Model 느슨한 결합)

다음은 3가지 패턴을 비교해본다.

MVC

• 입력은 Controller 로 들어온다.
• View-Controller 관계는 One-to-Many(일대다 관계)이다. Many-to-Many(다대다) 가 될 수도 있다.
• View 는 Controller 의 존재를 모른다. (=Controller 가 원하는 View 를 선택)
• View 는 Model 의 변화에 대해 직접적으로 알지 못한다. (옵저버 패턴과 같은 방식으로 간접적으로 인지)

MVC 패턴의 경우에는 규모가 커질수록 Controller 가 비대해진다.

하나의 예를 들면, Controller 가 다수의 View 를 선택할 수 있듯이 하는 일이 너무 많아질 수 있다.

또한 많은 패턴으로 인해, 복잡성이 증가함에 따른 문제점들이 발생한다.

MVP

• 입력은 View 로 들어온다.
• View-Presenter 는 One-to-One(일대일) 관계이다.
• View 는 Presenter 를 참조하고, Presenter 는 View 의 존재를 알고 있다. (강한 결합 = 서로 의존성이 높다)
• View 는 Model 의 존재를 모른다.
• Presenter 는 Model 을 업데이트하고, 원하는 데이터를 가져온다.

View와 Model 은 오로지 Presenter 에 의해서만 상호작용을 하게 된다.

그로 인해 View-Model 관계는 분리되었지만, View-Presenter 관계는 서로 강하게 의존한다.

코드 상으로는 View-Presenter 일대일 관계로 인해, 각 View 를 위한 각 Presenter 가 필요하다는 것이다.

코드의 수가 상당히 증가하게 된다.

MVVM

• 입력은 View 로 들어온다.
• View-ViewModel 관계는 One-to-Many 관계이다.
• ViewModel 은 View 의 존재를 모른다.
• View 는 Model 의 존재를 모른다.
• ViewModel 은 Model 을 업데이트한다.

MVVM 은 MVC 와 유사하다.

Controller 역할을 하는 ViewModel 은 이름 그대로 View 를 위한 Model 이라고 보면 된다.

여기서 View 를 위한 Model 은 일반적인 Model 이 아닌 특정 View 에게 맞춰진 Model 을 의미한다.

그로 인해, View 는 ViewModel 만을 고려한다.

결과적으로 View-Model 관계는 분리된다.

MVP 의 문제점인 View-Presenter 관계의 의존성은 데이터 바인딩과 명령을 통해 해결하게 된다.

View 가 단순히 시각적 표현을 위해 명령만을 받았다면, MVVM 은 반대가 된다.

현재 많은 변화를 요구하는 사용자 인터페이스에 있어, View 를 위한 View 가 중심이 되는 패턴이라고 볼 수 있다.

참고로 Vue.js 는 MVVM 패턴을 부분적으로 참고하여 만들어졌다.

Vue.js 가 ViewModel 의 역할을 하는 것이다.

패턴은 많은 측면에서 개발에 도움을 주기 위한 수단으로써 필수가 아닌 선택이다.

또한 MVP, MVVM 이 MVC 에서 파생되었다해도, 더 좋은 개발 방법론이라고 말할 수 없다.

어떤 언어가 더 좋다고 말할 수 없는 것과 같다.

목적과 환경에 따라 어떤 패턴이 어울릴 지 고민해야한다.

예를 들면, 안드로이드 개발환경 특성상 View 와 Controller 의 역할을 분리할 수 없어, MVP 또는 MVVM 을 선호한다고 한다.

참고 링크

http://blog.iandavis.com/2008/12/what-are-the-benefits-of-mvc/

https://tomyrhymond.wordpress.com/2011/09/16/mvc-mvp-and-mvvm/