👨💻 애플 공식문서를 통해 MVC 대해 정리합니다.MVC as a Compound Design Pattern
Model-View-Controller 패턴은 몇 가지 기본적인 디자인 패턴들로 구성된 패턴이다. 전통적인 형태의 MVC패턴은 Cocoa에서 사용하는 것과 Controller 그리고 View에 부여된 역할에서 약간의 차이가 있다.
스몰 토크 개념에서 MVC는 Composite, Strategy, Observer 패턴으로 구성되었다. 각 디자인 콘셉트가 어떻게 결합되었는지 알아보자.
# Composite
- 애플리케이션에서 View 객체는 (View의 계층 구조처럼) 구조화된 방식으로 함께 작동하는 View들이 중첩된 Composite 형태를 띤다.
- 여러 요소들이 합쳐진 TableView, UILabel을 포함하고 있는 UIButton, 여러 요소들을 Subview들로 갖고 있는 View들이 그 예시이다.
- User input 및 display는 Composite 구조의 모든 단계에서 발생할 수 있다.
# Strategy
- Controller 객체는 View 객체에 대한 전략을 구현한다. View 객체는 시각적인 면을 맡는 것으로 제한되며 인터페이스 동작과 같은 애플리케이션에서의 모든 결정을 컨트롤러에게 위임한다.
# Observer
- Model 객체는 관찰 관계에 있는 객체(일반적으로 View를 가리킴)에게 변경 사항에 대해 알려준다.
복합 패턴으로서의 전통적인 MVC 패턴을 도식화하면 다음과 같다.
Cocoa 애플리케이션에서의 MVC는 한 가지 개념이 추가되었는데 그것은 View 객체와 Model 객체는 "재사용"이 가능해야 한다는 것이다.
먼저 View부터 보면, View는 애플리케이션의 "look and feel"을 결정하기 때문에 모양과 동작의 일관성이 필수적으로 요구되며 이를 위해서는 재사용성이 높은 객체가 필요하다.
Model은 정의에 따라 특정한 문제의 도메인과 관련된 데이터에 대한 작업을 수행하도록 설계되어야 한다. 동일한 문제 도메인에서 이를 재사용할 수 있도록 구성하는 것이 좋다.
또한 디자인 측면에서도 더 나은 재사용성을 위해 Model과 View를 서로 분리하여 유지하는 것이 유리하다.
복합 패턴으로서의 Cocoa MVC 패턴.
Controller 객체는 Mediator 패턴과 Strategy 패턴을 통합하여 사용한다. 가장 중요한 차이점으로, Model과 View 사이의 데이터 흐름을 양방향으로 조정하며 Model의 상태 변경사항은 Controller를 통해 View 객체에 전달된다.
View는 Command 패턴의 target-action 매커니즘의 구현을 사용한다.
또한 Cocoa MVC 패턴은 위의 이론적인 이유 외에도 보다 실용적인데, 다음 그림을 보자.
Coordinating Controller는 Nib file로 묶인 Mediating Controller를 소유하고 있다.
Mediating Controller는 Mediator 패턴을 구현하는 것 외에도 애플리케이션의 많은 기능들을 구현해야 한다. 그러나 Model 객체에서 상태 변경사항을 보낼 때 Notification을 사용한다면, 그 알림에 대한 등록 및 처리를 하기 위해 커스텀한 View 클래스를 생성해야 한다.
Cocoa MVC 패턴은 Mediating Controller와 View를 Nib file로 묶어 이러한 Data flow를 실용적으로 관리할 수 있다.
이 부분을 정리하면 다음과 같다.
1. Controller를 Coordinating과 Mediating으로 분리한다.
2. 각각의 모든 View에다 Notification 등록을 하는 것은 일일이 custom View를 만들어야하고 불필요한 작업의 반복이 일어나므로 Controller에서 Notification을 등록하고, Controller가 중재자로서 이를 View에다 전달한다.
3. 따라서 그림과 같은 형태가 됨.
Design Guidelines for MVC Applications
애플에서는 애플리케이션 설계 시 odel-View-Controller에 대한 몇 가지 지침을 제공한다.
- Controller를 만들 때 이미 정의되어 있는 NSController의 서브 클래스들을 상속받아 사용하라. 굳이 NSObject의 서브 클래스 인스턴스를 사용하여 만들 필요가 없다.
- Model, View, Controller의 역할을 분리하라. 셋 중 하나의 객체가 다른 객체의 역할을 포함하도록 구현할 수도 있지만, 역할 분리를 유지하는 것이 재사용성과 확장성을 향상시킨다.
- MVC 애플리케이션의 목적은 재사용 가능한 개체를 최대한 많이 사용하는 것이다. View와 Model은 재사용성이 높아야 한다.
- View가 Model을 직접 관찰하여 상태 변화를 감지할 수도 있지만 항상 Controller를 거치게 만드는 것이 좋다. 그 이유는 다음 두 가지가 있다.
- View가 Model을 직접 관찰하는 binding 메커니즘을 사용하는 경우 Controller가 있기에 얻는 모든 이점들을 잃게 된다.
- binding 메커니즘을 사용하지 않는 경우 View들을 서브클래싱 하여 Model의 상태 변화 알림을 관찰하도록 한다.
- 애플리케이션의 클래스들의 코드 종속성을 최대한 제한하라. 다른 클래스에 대한 종속성이 클수록 재사용 가능성이 줄어들기 때문이다.
References
