상황

상당수 컴퓨터 시스템의 용도는 데이터 저장소에서 데이터를 검색하여 사용자에게 보여주는 것입니다. 사용자가 데이터를 변경하면 변경된 데이터는 시스템의 데이터 저장소에 저장됩니다. 정보가 주로 데이터 저장소와 사용자 인터페이스 사이에 전달되므로 이 두 개체를 서로 연결하여 코딩의 양을 줄이고 응용 프로그램 성능을 향상시키려고 할 것입니다. 하지만 이 자연스러워 보이는 방법에도 몇 가지 중요한 문제점이 있습니다. 한 가지 문제점은 사용자 인터페이스가 데이터 저장소 시스템보다 훨씬 더 자주 변하기 쉽다는 것입니다. 또 다른 문제점은 데이터 저장소와 사용자 인터페이스를 연결할 때 비즈니스 응용 프로그램에는 데이터 전송을 훨씬 넘어서는 비즈니스 논리를 통합하기 쉽다는 것입니다.

문제점

사용자가 쉽게 개별 파트를 수정할 수 있도록 웹 응용 프로그램의 사용자 인터페이스 기능을 모듈화할 수 있는 방법은 무엇일까요?

강제 요인

이러한 상황에서 다음과 같은 강제 요인이 시스템에 작용하며 위의 문제를 해결할 때 이러한 강제 요인을 조정해야 합니다.

솔루션

MVC(Model-View-Controller) 패턴은 도메인의 모델링과 프레젠테이션 그리고 사용자 입력 기반의 작업을 세 개의 별도 클래스로 구분해 줍니다[Burbeck92].

그림 1은 세 가지 개체의 구조적 관계를 나타냅니다.

그림 1: MVC 클래스 구조

중요한 점은 뷰와 컨트롤러는 모델에 의존하지만 모델은 뷰와 컨트롤러에 의존하지 않는다는 것입니다. 이것이 바로 구분의 가장 큰 이점입니다. 이 구분에서는 시각적 프레젠테이션의 영향을 받지 않으면서 모델을 만들고 테스트할 수 있습니다. 상당수의 리치(rich) 클라이언트 응용 프로그램에서는 뷰와 컨트롤러 사이의 구분이 그다지 중요하지 않으며 실제로 상당수 사용자 인터페이스 프레임워크에서는 두 역할을 하나의 개체로 구현합니다. 반대로 웹 응용 프로그램에서는 뷰(브라우저)와 컨트롤러(HTTP 요청을 처리하는 서버측 구성 요소) 사이의 구분이 명확하게 정의됩니다.

MVC(Model-View-Controller) 는 사용자 인터페이스 논리와 비즈니스 논리를 구분하기 위한 기본적인 설계 패턴입니다. 불행히도 이 패턴의 인기로 여러 잘못된 설명이 나타났습니다. 특히 "컨트롤러"라는 말은 다양한 여러 상황마다 다른 의미를 가지게 되었습니다. 하지만 다행히 웹 응용 프로그램의 등장으로 뷰와 컨트롤러 사이의 구분이 명확해짐에 따라 어느 정도의 모호함이 해결되고 있습니다.

변형

Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC)[Burbeck92]에서 Steve Burbeck는 MVC의 두 가지 변형인 수동 모델과 능동 모델에 대해 설명합니다.

수동 모델은 하나의 컨트롤러가 모델을 독자적으로 처리할 때에 사용됩니다. 모델을 수정한 컨트롤러는 해당 모델이 변경되었으며 새로 고쳐야 함을 뷰에 알려줍니다(그림 2 참조). 이 시나리오에서는 모델이 뷰와 컨트롤러로부터 완전히 독립되어 있기 때문에 모델이 상태 변경 사항을 보고할 방법이 없습니다. HTTP 프로토콜이 바로 그 예입니다. 브라우저에는 서버로부터 비동기 업데이트를 받을 수 있는 간단한 방법이 없습니다. 브라우저는 뷰를 표시하고 사용자 입력에 응답하지만 서버의 데이터가 변경되는 것을 감지하지 못합니다. 사용자가 명시적으로 새로 고침을 요청해야만 서버에 변경 사항이 있는지 물어봅니다.

그림 2: 수동 모델의 동작(behavior)

능동 모델은 컨트롤러의 개입 없이 모델이 상태를 변경할 때에 사용됩니다. 이러한 경우는 다른 소스가 데이터를 변경 중일 때 이 변경 사항을 보기에 반영해야 하는 경우에 발생할 수 있습니다. 증권 시세 표시기를 생각해 보겠습니다. 주식 데이터가 변경되면 외부 소스에서 주식 데이터를 받아 뷰(예: 시세 표시기 및 경보 창)를 업데이트하고 싶습니다. 오직 모델만이 변경된 내부 상태를 감지할 수 있기 때문에 변경이 발생할 경우, 모델은 표시기를 새로 고치도록 뷰에게 통보해야 합니다.

하지만 MVC 패턴을 사용하는 이유 중 하나는 모델이 뷰의 영향을 받지 않기 때문입니다. 모델이 뷰에 변경 사항을 통보해야 한다면 지금까지 피하려고 했던 의존성이 재현되는 것입니다. 다행히도 옵서버 패턴[Gamma95]은 의존성을 재현하지 않고도 상태 변경 사항을 다른 개체에 알려줄 수 있는 메커니즘을 제공합니다. 개별 뷰가 옵서버 인터페이스를 구현하고 모델에 등록합니다. 이 모델은 변경 사항을 구독하는 모든 옵서버의 목록을 추적합니다. 모델이 변경되면 이 모델은 등록된 모든 옵서버를 검색한 후 옵서버에게 변경 사항을 통보합니다. 이 방법을 흔히 "게시-구독"이라고 합니다. 모델에는 뷰에 관한 특정 정보가 전혀 필요 없습니다. 실제로 모델 변경 사항(예: 메뉴 옵션 설정 또는 해제)을 컨트롤러에 알려야 하는 시나리오에서는 모든 컨트롤러가 옵서버 인터페이스를 구현하고 모델 변경 사항을 구독해야 합니다. 많은 뷰가 있는 상황에서는 여러 개의 주제를 정의하고 각 주제로 특정 유형의 모델 변경 사항을 설명하는 것이 좋습니다. 각각의 뷰는 해당 뷰에 관련된 유형의 변경 사항만을 구독할 수 있습니다.

그림 3은 옵서버를 사용하는 능동 MVC의 구조와 모델이 뷰를 직접 참조하지 못하도록 옵서버가 모델을 격리시키는 방법을 보여줍니다.

그림 3: 능동 모델에서 옵서버를 사용하여 모델과 뷰를 분리

그림 4는 모델이 변경될 때 옵서버가 뷰에 어떻게 변경 사항을 통보하는지 그 방법을 보여줍니다. 불행히도 모델과 뷰의 구분을 UML(Unified Modeling Language) 시퀀스 다이어그램에 적절하게 표시할 수 있는 방법이 없는데 그 이유는 이 다이어그램은 클래스와 인터페이스가 아니라 개체 인스턴스를 표시하기 때문입니다.

그림 4: 능동 모델의 동작(behavior)

예제

ASP.NET에서 MVC(Model-View-Controller 구현을 참조하십시오.

테스트 고려 사항

MVC(Model-View-Controller) 패턴을 사용하면 테스트 성능이 상당히 향상됩니다. 구성 요소가 상호 의존적인 경우 구성 요소(특히 사용자 인터페이스 구성 요소)를 테스트하는 것이 어려워집니다. 이런 구성 요소의 경우는 간단한 기능을 테스트하는 데도 복잡한 설정이 필요합니다. 설상가상으로 오류가 발생한 경우에는 문제를 특정한 구성 요소에 격리시키는 것이 어렵습니다. 바로 이러한 이유 때문에 Architecture를 구성하는 데 있어 구분이 중요해집니다. MVC에서는 데이터의 저장, 표시 및 업데이트 문제를 세 개의 구성 요소로 구분한 후 이 구성 요소를 개별적으로 테스팅할 수 있습니다.

상호 의존성에 의한 문제는 제외하더라도 사용자 인터페이스 프레임워크의 테스트 자체가 어렵습니다. 사용자 인터페이스를 테스트하기 위해서는 지루한 수작업 테스트(오류가 발생하기 쉬운 테스트)나 사용자 동작을 시뮬레이션하는 테스트 스크립트가 필요합니다. 이 스크립트는 개발에 많은 시간이 소요되며 불안정합니다. MVC가 사용자 인터페이스 테스트의 필요성을 없애주지는 않지만 모델과 프레젠테이션 논리를 구분하기 때문에 프레젠테이션의 영향을 받지 않고 모델을 테스트할 수 있으므로 사용자 인터페이스 테스트 사례의 수가 줄어듭니다.

결과

MVC 패턴 주위에 프레젠테이션 레이어를 구성하면 다음과 같은 이점과 단점이 있습니다.

이점

단점

변형

문서-보기 변형 패턴은 MVC(Model-View-Controller) 의 세 가지 역할을 모드 인식하지만 컨트롤러를 보기에 병합합니다. 문서는 MVC의 모델 역할에 해당합니다. 이 변형 패턴은 기존의 상당수 GUI 플랫폼에 나타납니다. 문서-보기의 가장 좋은 예는 Microsoft Visual C++ 환경의 MFC(Microsoft Foundation Class) 라이브러리입니다. 이 변형 패턴을 사용할 때는 뷰와 컨트롤러가 약간 더 긴밀하게 연결됩니다.

관련 패턴

자세한 내용은 다음과 같은 관련 패턴을 참조하십시오.

참고 자료

MVC(Model-View-Controller) 는 1970년대 후반 Trygve Reenskaug가 Smalltalk 플랫폼용으로 개발한 프레임워크로 출발했습니다[Fowler03]. 방금 읽은 이 버전에서는 다음과 같은 문서를 참조합니다.

[Burbeck92] Burbeck, Steve. "Application Programming in Smalltalk-80: How to use Model-View-Controller (MVC)."University of Illinois in Urbana-Champaign (UIUC) Smalltalk Archive. 다음 웹 사이트에서 구할 수 있습니다: http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html (영문).

[Fowler03] Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2003.

[Gamma95] Gamma, Helm, Johnson 및 Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.