MVC

프런트 앤드를 위한 MVC?

MVC는 서버 사이트 코드를 구조화하고 모듈로 만들며 유지보수가 용의하도록 돕는 매우 잘 알려진 디자인 패턴입니다. 그러면 프런트 앤드에서 MVC를 사용하려면 어떻게 해야 할까요? 자바스크립트에서 이 디자인패턴을 적용할 수 있을 까요? 만약 여러분이 자바스크립트를 단지 애니메이션과 폼 유효성 검사, 100라인이 넘지 않는 간단한 처리를 위해서 사용한다면 MVC를 사용해서 여러분의 스크립트 파일을 구조화할 필요 없습니다. RequireJS도 사용할 필요 없을 겁니다. 하지만, 뷰(view)가 많은 리치 웹 앱을 제작 중이라면 반드시 필요합니다!

Model 과 View 그리고 서로간의 관계

Model

모델은 도메인 개체 그 자체이다. 도메인은 프로그램 내에서 동일한 의미를 갖는 대상이다. 보통 Data 그 자체와 동일시 되지만, 이 외의 데이터를 조작할 수 있는 기능이 추가되기도 한다. 구현과 상황에 따라서는 단순히 데이터소스에 접근하는 DAO 역할을 하거나,  파일 시스템 자체가 되거나, 라이브러리 세트가 된다.

View

디스플레이.

사용자(Client. 사람이 아닌 기계 혹은 동물일수도 있다. 어플리케이션이 이용되는 타겟이라고 생각하자) 에게 제공되는 UI Layer를 말한다. 더욱 큰 의미를 포함하면 눈으로 이미지가 곁들여지거나 글자로 이루어지지 않은 바이트 코드의 나열이나 음악 파일등이라도, Client 가 이해할 수 있다면 View가 될 수 있다.

보통 Web Application 등에서는 View는 HTML/CSS 로 렌더링된 화면을 가르킨다.

둘의 관계..

MVC를 비롯한 여러 프레임워크들이 나온 이유는 명확하다.

각 계층의 분리로 재활용성을 높이고 중복을 막자는 것이다. 각 계층의 강한 결합이 발생한다면 애초에 프레임워크를 적용하는 의미가 없다.

이 둘의 의존성을 어떻게 제어하느냐에 따라 MVC, MVP, MVVM … etc 등으로 나뉘게 된다.

 

Controller, Presenter, ViewModel…?

이들은 모델과 뷰의 통신을 담당한다. 이들의 차이점을 한번 훓어보자.

Controller

모든 입력은 Controller에서 처리된다. 특정 입력이 들어오면 Controller는 그 입력에 해당하는 Model을 선택하여 처리하게 한다.

Controller는 입력에 따라 Model을 업데이트하고, 결과에 따라 다른 View를 선택한다. Controller는 View를 선택할 수 있기에 View를 여러개 관리할 수 있다.

일반적으로 View는 Model을 사용하여 업데이트를 하지만, Model을 관리하는 것은 Controller이므로 사실상 View는 Model을 직접적으로 생성하거나 관리하는 것은 아니다. Model을 이용하거나 이용될 뿐이다.

Controller는 Model을 조작하고 View를 선택하지만 View를 직접 업데이트하진 않는다.

이 경우에는 View와 Model의 관계가 어느정도 있으며

• View가 Model을 직접 사용하여 업데이트가 되거나,
• 아니면 Model은 자신과 관련돤 View 들에게 Notify 해줘서 View가 업데이트 되는 방식도 있고,
• View가 polling 을 통해 Model의 변화를 알아채고 스스로 업데이트하는 방식도 있다.

어느것이 되었든 View와 Model의 어느정도의 의존성은 피할 수 없다. 이것이 Controller를 사용하는 MVC의 문제점이라면 문제점이다.

MVC 패턴의 좋은 구성은 최대한 이 둘의 의존성을 낮추는게 관건이다.

조금 억지스러운 예를 들어보자.

View와 Model이 클럽에 온 소극적인 남녀라면 Controller는 이 둘을 부킹해주는 실력좋은 웨이터이다. 여기서 소극적인 이라는게 중요하다. 물론 웨이터는 수 많은 요청에 의해 오늘도 매번 부킹에 성공할 것이다.

Presenter

View와 Model 사이의 상호작용을 담당한다. 또한, 이 경우 사용자의 입력 처리는 Controller 가 아닌 View가 담당한다. View가 이벤트를 Presenter에 전달하면 이벤트에 맞춰 Presenter는 Model을 조작하고 그 결과를 다시 View에 바인딩하여 View의 요소들이 업데이트된다.

Controller는 단순히 View를 선택하고 Model을 조작한 뒤 실제 회면 갱신은 View와 Model의 상호작용으로 이루어지지만 Presenter 를 사용한 MVP에서는 Presenter가 Model을 조작하고 관리하며 변경이 있으면 Model에 따라 View를 업데이트하게 된다.

실제 구현체로 생각해본다면 Presenter는 Model과 View의 인스턴스를 모두 가지고 있어야 할 것이다. View가 섬이고 Model이 육지라면 그 사이를 이어주는 다리와 같다고 보면 될 듯 싶다.

View와 Presenter는 1:1 관계로 맺어지며 Presenter는 보통 Model보다는 View에 더 닮은 구조로 디자인된다.

MVC와는 다르게 View와 Model의 관계가 전혀 없으며 단지 View는 Presenter라는 것을 하나씩 가지고 있게 된다. 그리고 입력 처리를 View에서 처리한다는 점도 큰 차이점이 된다.

이 녀석을 사용하면 View와 Model의 의존관계가 완전히 없어진다.

ViewModel

View의 표현을 담당한다고 보면 되겠다.

MVP와 매우 비슷하지만 큰 차이점이라면 비중이 View에 좀더 치우쳐 있다는 점이며, Presenter는 View에 상당한 의존성이 있었지만, Controller, Presenter의 위치인 ViewModel은 View와 아무런 관련이 없다. 여러 View들은 하나의 ViewModel을 선택하여 바인딩하고 업데이트를 받는다.

ViewModel의 디자인은 View보다는Model에 비슷하게 구성된다. 보통 ViewModel이 변경되면 자동으로 View에 업데이트되는 방식으로 구현된다.

Model이 순수한 Model이라면 ViewModel은 View를 위한 모든 커스터마이징을 제공하는 Model이다.

좀 억지를 부려보면, ViewModel이 회사라면 View는 근무하는 사원에 가깝다. 회사는 사원의 여러 근무에 대한 환경을 제공한다. 이윤을 위해서라면 회사는 그 무엇과도 거래하고 연결한다.

min