• MVC, MVP, MVVM 무엇인가? :: 마이구미
    디자인 패턴 2018. 3. 26. 22:03
    반응형

    이 글은 디자인 패턴 중 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 패턴으로 표현할 수도 있다.


    MVC


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


    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, mvp, mvvm


    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/

    반응형

    댓글

Designed by Tistory.