Model-View-Controller

모델-뷰-컨트롤러, 줄여서 MVC 패턴은 패턴 이상의 구조물이라고 간주됩니다. 왜냐하면 이것은 응용 프로그램을 정리하는 기본적인 방법이며 모든 패턴들을 아우르는 상위의 구조적인 요소이기 때문입니다. 왜냐하면 이것은 코코아 기반 응용 프로그램 구성의 기본 방법이며, 이것을 패턴의 요소로서 그리고 코코아를 이용할 때에 맞는 설계 철학으로 다루는 것이 타당합니다.

MVC 구조는 1970년대 Smalltalk에서 처음 사용되었고, 가장 성공적이고 일반적으로 상위 레벨의 응용 프로그램 구성에 사용되는 구조로서 검증되었습니다. 모든 프로그램들은 다른 구조적인 요구를 갖고 있습니다. MVC는 모든 경우를 만족하지는 못하지만, 대부분의 그래픽 응용 프로그램에 잘 맞는 구조입니다.

MVC는 응용 프로그램을 세 가지 주요한 부분 혹은 계층으로 나눕니다. 각 부분은 여러 객체들로 구성되고 MVC 개념 안에서 각각의 책임과 임무가 부여됩니다. 각 계층의 이름이 이 패턴의 이름입니다.


Model: 이것은 응용 프로그램의 심장으로서, 응용 프로그램 고유의 데이터 구조와 핵심 로직을 갖고 있습니다.

View: 이것은 사용자의 입력과 출력을 제공하는 책임이 있습니다. 일반적으로는 그래픽이지만, 텍스트 기반, 웹 기반, 혹은 스크립트 기반일 수도 있습니다.

Controller: 이것은 Model과 View의 동기화와 유저로부터의 입력을 담당합니다. 컨트롤러를 두는 이유는 Model과 View을 분리하여 각각이 서로 독립적으로 분리 교체될 수 있도록 하기 위함입니다.


만약 어떤 잘 정리된 대량의 데이터를 위한 에디터 프로그램을 만든다고 할 때 MVC는 프로그램의 내부 구성의 자연스러운 방법이 될 것입니다. 데이터는 모두 모델에 저장되고, 뷰는 윈도우나 인터페이스로서 사용자에게 데이터를 제공하는 프로그램이 됩니다. 컨트롤러 계층은 이 둘을 묶어주는 역할을 합니다.

코코아는 각 계층에 대해서 자세히 설명하여 이러한 종류의 응용 프로그램 구조에 잘 맞도록 강조하고 있습니다.


Model
모델은 응용 프로그램의 중심 알고리듬과 데이터 구조를 담고 있어야 합니다. 모델은 응용 프로그램의 내부 상태와 각 응용 프로그램 특유의 코드 대부분을 담고 있는 응용 프로그램의 핵심입니다. 모델은 여러 다른 종류의 컨트롤러와 뷰 서브시스템에 재사용될 수 있어야 합니다. 이렇게 하기 위해서는 컨트롤러나 뷰에 종속되지 않은 코드로 작성되어야 합니다.

View
뷰는 응용 프로그램의 유저 인터페이스를 담고 있습니다. 대부분의 그래픽 프로그램에서 유저 인터페이스는 유저가 모델의 데이터를 특정 알고리듬으로 보고 수정할 수 있도록 하는 것입니다. 만약에 유저 인터페이스가 프로그램에서 가장 치명적이고 복잡한 부분일 경우는 기억하십시오, 특정한 유저 인터페이스는 모델이 없이는 보거나 수정할 수 있는 데이터가 없지만, 모델은 어떠한 종류의 유저 인터페이스에도 적용될 수 있습니다. 더군다나 역사적으로 프로그램에서 유저 인터페이스의 개발은 프로그램을 단순화를 위한 것이었고, 그 대신에 사용 가능한 유저 인터페이스 개발 장비를 복잡하게 하였습니다. 코코아 응용 프로그램의 유저 인터페이스는 출력되는 모델보다 복잡하지 않아야 합니다. 대부분의 코코아 프로그램에서 뷰에는 어떠한 코드도 첨가되지 않습니다. 예를 들어, 파일 시스템을 보여주는 프로그램은 파일 시스템을 컬럼 브라우저, 아웃라인, 테이블, 혹은 터미널같은 스크롤 텍스트로 표현할 수 있습니다. 이 중에 어떤 부분도 다양한 코코아 프레임웍과 인터페이스 빌더 클래스들 외에 특별히 코드를 작성해야 할 필요가 없습니다.

뷰에는 특별한 유저 인터페이스 고유의 상태 외에 응용 프로그램의 상태를 저장하고 있으면 안됩니다. 예를 들어, 문서가 보여지는 비율은 문서의 뷰 고유의 것입니다. 버튼의 모양은 유저 인터페이스 내의 버튼의 목적에 따라 달라집니다. 이런 특성은 뷰 고유의 것입니다. 하지만, 출력되는 문서의 정보라든지 버튼에 대입된 값 등은 모델에 기록되어야 합니다.

이상적으로는 뷰 서브시스템과 모델 서브시스템은 상호 종속성이 없어야 합니다. 하지만, 종속성을 피하는 것이 불가능할 때에는 그 종속성이 완전히 특정한 뷰와 모델에서만의 것이지 다른 방법으로는 안됩니다. 서브시스템의 종속성은 어떤 한 서브시스템을 다른 것으로 교체할 때 문제를 발생합니다. 모델 내의 코드는 시간이 지날 수록 안정화되고 성숙되어 가지만, 유저 인터페이스는 계속해서 개량되어 갑니다. 만약에 모델을 바꿀 때 뷰도 바꾸어야 한다면 뷰 쪽은 언제든지 바뀔 수 있기 때문에 그 비용은 경감됩니다. 더군다나, 대부분 뷰를 바꾸는 것은 인터페이스 빌더에서 수행되고 다른 코딩이 필요가 없습니다. 뷰를 바꾸면서 모델도 바뀌어야 한다면 추가 비용이 발생하게 되고 이런 것은 지양되어야 합니다.

Controller
이상적인 시스템은 뷰의 서브시스템과 모델 서브시스템은 상호 의존성이 없어야 합니다. 컨트롤러 서브시스템은 뷰와 모델의 의존성을 줄이는 역할을 합니다. 컨트롤러는 다른 서브시스템 사이에 주입된 계층입니다. 컨트롤러의 목적은 모델의 변경에 따른 뷰의 변경, 혹은 그 반대의 경우를 방지하기 위함입니다.

뷰나 모델이 변경되면 보통 컨트롤러의 변경을 필요로 하게 됩니다. 따라서 컨트롤러는 이러한 변화에 따른 비용 절감을 위하여 최대한 단순화해야 합니다. 컨트롤러에는 프로그램의 상태에 대한 어떠한 정보도 담겨있지 않아야 합니다. 예를 들어, 모델 내에 저장된 정보를 지우기 위하여 버튼을 누른다면 버튼을 누르는 행동은 컨트롤러 서브시스템이 처리합니다. 컨트롤러는 정보를 삭제하기 위하여 모델이 제공하는 API를 호출하도록 구현되어야 합니다. 그 다음 컨트롤러는 뷰의 API를 호출하여 이 경우는 화면 갱신을 뷰에게 요구하는 것으로 정보 삭제에 대한 반영을 요구합니다. 이런 식으로 컨트롤러가 운용되면 정보를 삭제하는 유저 인터페이스는 모델을 변경할 필요 없이 메뉴 혹은 스크립트 명령을 변경하는 것만으로 구현이 가능합니다. 비슷한 예로, 모델은 특정 정보에 대한 삭제 불가 등의 변경을 유저 인터페이스의 변경 없이 할 수 있습니다.

코코아에서의 MVC
이렇게 세 계층으로 나눔으로써 응용 프로그램의 인터페이스와 데이터가 분리됩니다. 그럼으로써 응용 프로그램의 재사용 가능성이 높아지게 됩니다. 따라서 텍스트 필드같은 일반적인 뷰 객체들을 만들어서 여러 가지 다양한 응용 프로그램에 재사용할 수 있게 됩니다. 모델은 각 프로그램마다 다르게 구현되어 여러 가지 방법으로 데이터를 활용하거나 변경할 수 있습니다. 예를 들어, 어떤 어플리케이션이 어떤 데이터를 조작하면서 또 다른 커맨드 라인 혹은 웹 인터페이스가 동일한 데이터를 접근하도록 만들 수 있습니다. 일반적인 뷰 클래스와 특수한 모델 클래스는 재사용될 수 있으며, 일반적인 컨트롤러 클래스는 서로 관계 없는 응용 프로그램들을 재사용할 수 있게 합니다.

Foundation Kit에는 모델에 따른 다양한 데이터 구조를 제공하여 다른 기본 데이터 구조를 재구현할 필요 없이 모델 특유의 작업에만 전념할 수 있게 도와줍니다. 이론적으로 모델 계층이 여러분의 프로그램 고유의 기능으로 여러분의 대부분의 프로그래밍 시간을 할애해야 할 부분입니다.

코코아는 Application Kit에 아주 다양한 뷰를 제공하고 있어서 각각의 프로그램들이 자신들의 뷰를 따로 제작하지 않아도 될 것입니다. 코코아를 이용하면서 작업 시간도 절약되고 생산성도 향상되도록 하는 길입니다.

만약에 여러분이 문서 중심의 프로그램을 만든다면 NSDocument 계열의 다양한 클래스들이 여러분이 필요로 하는 컨트롤러 구조를 제공하게 될 것입니다. NSDocument 클래스는 9장 "Applications, Windows, and Screens"에서 설명하고 있습니다. 불행하게도 코코아에서는 아직 다른 컨트롤러 계층에 대해서는 크게 도움을 제공하지 못하고 있습니다. Application Kit은 뷰 계층을, Foundation Kit은 모델 계층에 촛점이 맞추어져 있습니다. 아직 일반적인 controller framework 계층은 없습니다.

컨트롤러 프레임웍은 코코아가 개선해야 할 부분입니다. 그러나 일반적인 컨트롤러 객체 제작에 도움이 될 수 있는 것들을 애플은 제공하고 있습니다. 엔터프라이즈 객체 프레임웍에 포함되어 있는 EOInterface 프레임웍입니다. 아쉽게도 이것은 코코아의 일부가 아니라서 모든 코코아 개발자들이 사용할 수 있는 것은 아닙니다. 아마도 머지않은 장래에 이러한 클래스나 혹은 비슷한 것들이 코코아의 일부가 될 것입니다.

그때까지는 코코아 자체에서 제공하는 컨트롤러 프레임웍은 없습니다. 따라서 여러분은 응용 프로그램의 컨트롤러 레이어를 위한 코드를 짜 주어야 합니다. 대부분의 개발자들은 재사용 가능하고 일반적인 컨트롤러 클래스는 어렵고 클래스 설계에 시간이 많이 걸리기 때문에 구현하지 않습니다. 아주 극소수의 개발자들만이 그 일을 제대로 할 수 있는 시간과 자원이 있기 때문에 대부분 코코아 프로그램 개발자들은 고유의 컨트롤러 클래스를 그 때마다 개발해서 씁니다. 대부분 프로젝트의 시간 계획을 고려하면 이것은 합리적인 선택입니다. 그러나 이러한 커스텀 클래스들은 다음번 응용 프로그램에서 재사용될 가능성이 희박합니다.

가끔은 MVC 구조에 잘 맞지 않는 두 가지 기능, undo와 preferences/defaults 기능을 코코아 응용 프로그램이 가져야 할 때가 있습니다. 이 기능들은 컨트롤러나 뷰에 쉽게 구현할 수 있습니다만 각각의 방법이 서로 배타적입니다. 예를 들어, preferences/defaults 의 입출력을 컨트롤러에 구현하고 유저 default를 다른 뷰로 처리하여 컨트롤러는 사용자 기본값과 모델 사이에서 데이터를 교환할 수 있습니다. 한편, 사용자 기본값은 응용 프로그램 상태와 같은 데이터를 가질 수 있으며 이것은 모델의 한 부분입니다. 그리고 undo 기능은 모델을 변경하는 저장된 명령의 한 종류로 간주될 수 있고, 따라서 스크립팅 시스템같은 다른 뷰는 컨트롤러를 통하여 모델과 정보를 교환할 수 있습니다. 반면에, undo 를 준비된 응용 프로그램의 상태로 간주할 수 있고, 따라서 모델에 구현되는 것이 좋습니다.

MVC 기법을 이용한 제작에 대한 자세한 사항을 다 하려면 책 한 권이 필요합니다. 객체 지향 설계에 대한 좋은 책들은 이러한 것을 잘 다루고 있으니 MVC 의 개념에 대해서 잘 이해가 안 되시면 책을 참조하시면 좋겠습니다. 이 책의 다른 장을 보시면서 MVC 의 개념을 염두에 두시면 여러분이 보게 될 수 많은 클래스들을 올바르게 응용할 수 있도록 도와줄 것입니다.