MVVM 패턴

[kongyaa]

MVVM 패턴은 MVC(Model/View/Controller) 패턴의 변형으로 뷰의 추상화를 만드는 것이 핵심

[kongyaa]

MVVM 패턴의 등장배경

MVC와 그 계량형 패턴들은 훌륭한 구조를 가지고 있지만 뷰, 로직에 이어 전체 애플리케이션에 프로그래머가 개입해야 한다.

개발자가 구현해놓은 화면에서 디자이너가 어떤 요소의 id나 class명을 바꾼다거나 하는 행동을 하면

해당 화면의 데이터나 요소가 제대로 표현되지 않을 수 있다.

이전의 개발방법은 위처럼 디자이너와 개발자의 관계가 너무 붙어있다.

이벤트를 실행하려면 각각의 요소에 name, id 혹은 class와 같은 식별자를 주어야 하기 때문에 복잡하게 엮일 수가 있다.

개발자가 뷰에서 #btn-file-del라는 id를 가진 버튼의 이벤트에 .file-del 이라는 요소만 삭제하도록 구현해놨는데,

디자이너가 개발자와 의논 없이 fiel-delete에 디자인을 입히거나 변경했다면 엉뚱한 위치에 표현되거나 기능이 동작하지 않는다.

UI 플랫폼이 발달하면서 모델, 컨트롤러와 프레젠터보다 뷰의 비중이 높아지면서 각 뷰의 데이터와 커맨드를 분리해야 한다.

이를해결하기 위해 MVVM 패턴이 등장한다.

[kongyaa]

MVVM 패턴

MVP의 프레젠터 컴포넌트가 뷰모델로 대체된다.

프레젠터가 뷰와 모델을 참조했던 것 중 뷰와의 의존이 직접적인 참조가 아니라

Event Driven 형태로 간접적인 접근을 수행함으로써 뷰와 뷰모델 사이의 연결고리를 약하게 만든다.

이로서 디자이너의 영역인 뷰와 프로그래머의 영역인 뷰모델-모델 영역이 분리되면서,

서로에게 최소한의 영향만 주며 작업을 수행할 수 있다.

뷰모델은 뷰를 추상화하며 뷰에 대해서는 아무것도 몰라도 되며,

단지 여러개의 뷰가 하나의 뷰모델을 참조하는 1:N 관계일 뿐이다.

View

뷰는 단순히 사용자 인터페이스를 표시하기 위한 로직만을 담당한다.

사용자의 입력정보를 수신하고, UI요소를 그린다.

뷰와 프레젠터의 역할을 모두 포함하게 된다.

이전에 포함되어있던 데이터와 커맨드(이벤트)는 ViewModel이 갖게 된다.

ViewModel

뷰모델은 View가 바인딩할 수 있는 프로퍼티와 커맨드를 담당한다.

뷰에게 보여줘야 할 데이터와 수정에 필요한 로직을 가지고 있다.

Model

모델은 응용 프로그램의 데이터 및 비즈니스 로직을 담당한다.

MVP와 매우 비슷하지만 큰 차이점이라면 비중이 View에 치중되어있다는 것이다.

프레젠터는 뷰에 상당한 의존성이 있었지만, 뷰모델은 뷰와 아무런 관련이 없다.

뷰는 하나의 뷰모델을 선택하여 데이터 바인딩을 수행하고 업데이트를 받는다.

모델이 비즈니스 로직의 순수한 모델이라면 뷰모델은 뷰를 위한 모든 커스터마이징을 제공하는 모델이다.

ExtJS

sencha ExtJS의 서비스 아키텍쳐는 뷰모델이 뷰모델과 뷰컨트롤러로 분리된다.

뷰는 여러가지 컴포넌트를 확장하고 조립하여 UI를 표현하며 뷰모델과 뷰컨트롤러를 지정한다.

뷰컨트롤러는 뷰를 추상화한 뷰모델의 이벤트를 정의한다.

뷰모델은 뷰를 추상화한 뷰모델의 데이터를 정의한다.

모델과 스토어는 별개로, 애플리케이션에서 정보의 게이트웨이 역할을 한다.

모델은 애플리케이션에서 지속 가능한 모든 형태의 데이터,

스토어는 클라이언트 측면에서 모델 클래스의 인스턴스를 캐싱한 컴포넌트로서 담고 있는 데이터의 정렬, 필터링 및 질의기능을 제공한다.