1. Intro

: 예전에 MVC의 원문을 읽고 요약했던 것에 이어서, 이번에는 MVP의 원문을 읽고 요약해보았다. MVC가 제안된 후로, 시간이 꽤 지나면서 Application의 요구사항이 복잡해지다보니... MVC의 Component를 좀 더 세분화 시킨 것이 눈에 띈다. MVP가 등장하던 시기에는 Unit Test의 중요성이 부각되진 않았는지 Testability의 장점에 대해선 언급되어 있지 않았다. Kent Beck의 XP 책이 1999년도에 등장했으니 그럴수도 있을 것 같다.

 MVP의 원문에서 이야기하는 핵심 내용을 잘 전달하려고 노력했지만, 개인 판단상 필요없다고 생각한 부분은 빼기도 했다. 맨 하단에 원문의 Link를 남겨두었으니, 부족한 부분이 있다면 찾아볼 수 있을 것이다.

 IBM의 자회사인 Taligent는 C++ & Java 언어로 개발하기 위한 차세대 Programming Model을 만들었는데, 그것에 MVP(Model View Presenter)이다. MVP는 Smalltalk의 고전적인 MVC Programming Model을 일반화한 것에 베이스를 둔다.

 MVP는 다양한 Application, Component 개발을 위한 강력하고, 이해하기 쉬운 설계(Design) 방법론을 제공한다. 또 MVP는, Multiple client / server 나 Multi-tier application architecture에도 적용할 수 있다. MVP는 주요 객체지향 언어 환경에서, 활용가능한 통합된 개념적 Programming model을 제공해줄 것이다.

2. Taligent에서 새로 제안한 Programming Model

2-1. Smalltalk Programming Model

: 1970년대, Smalltalk의 MVC model이 제안되었다. MVC는 Smalltalk에서 GUI 개발하기 위한 Fundamental design pattern으로 시작해서, 지금까지 다양한 Library들과 Application에서 재사용되고 채택되어 왔다.

 Smalltalk로 개발하던 개발자들은, Model, View, Controller를 추상화하기 위한 Base class(Smalltalk Class Library에서 제공함)들을 Customizing하거나 상속하여... GUI Object들을 만들었다. 개발자들은 GUI object에 있는, MVC에서 정의한 Model, View, Controller간 타이트한 결합을 이어받아, 개발할 때 편의를 누릴 수 있었다. 좀 복잡한 GUI object는 여러 GUI object들을 조합하여 구성할 수 있다. 궁극적으로는 모든 Graphical application은 MVC를 이용하여 구성할 수 있는 것이다.

2-2. Building the Taligent / Open Class Progamming model

: IBM을 위한 Open Class Library에서 Taligent는 다양한 Application의 전반적인 구조를 나타내기 위해, MVC Programming Model을 채택하고 일반화했다.

 Taligent는 전반적으로 기본적인 MVC Concept을 더 세분화한다. 우선, Model이랑 View와 Controller를 분리하고, View와 Controller를 합쳐서 Presentation이라 부른다. 이것은 Programming Problem을 Data Management와 User Interface라는 두 Fundamental Contept으로 분리하는 것이다.

3. Model

3-1. Model Enable Encapsulation

: Model Concept을 일반화하면 몇몇 이점이 있는데... 우선 Model과 Presentation이 깨끗하게 분리될 수 있다. 예를 들어, 전화번호 목록 Component를 구현한다고 가정해보자. Model은 이름과 전화번호에 대한 Data를 캡슐화(Encapsulate)한다. 그리고 Model에서, Data에 대해 Query하거나 Data를 수정하기 위한 Method를 제공한다. Presentation은 전화번호 목록을 표현하는 전화번호부가 될 수 있다.

 깨끗하게 분리하고 캡슐화함으로써 이점을 얻을 수 있다. Model이 Data Structure를 바꾸는 것처럼 크게 수정하더라도, Presentation은 아무런 수정없이 재사용할 수 있다. 비슷하게, UI 변경과 같이 Presentation을 크게 수정하더라도, Model은 아무런 수정없이 재사용할 수 있다.

3-2. Model enable Persistence

: Model내에 Data가 저장되기도 하지만, Model이 Data를 저장하지 않고 Persistent Data Store에 접근해서 저장된 Data를 사용하기도 한다. Model은 접근 제어나 인증 관련 Logic을 구현할 수도 있고, 회계 또는 과금 Logic을 구현할 수도 있고, 성능 향상을 위해 Cache를 구현할 수도 있다.

3-3. Model Enable Sharing

: Model을 추상화하면, 여러 사용자 간의 Data 사용을 유연하게 할 수 있다. 다른 Program의 Model이 동일한 Remote Data를 캡슐화하는 것은, 여러 사용자가 Data를 공유할 수 있게 해준다. 아래의 그림을 참고하면, 이해가 쉬울 것이다.

3-4. Three Data Management Questions

: Taligent는 Data Management와 UI를 분리하는 다양한 개발 경험을 바탕으로, Data Management의 문제를 정리했다. 그들은, 아래의 그림처럼 Data Management의 문제를 3개의 질문을 바탕으로 3 부분으로 나누었다.

1) What is my data?

: 위의 그림에서 Model에 해당하며, 우리가 알고있는 기존의 Model과 비슷하고 Data를 캡슐화하고 읽고, 쓸 수 있는 Method를 제공한다.

2) How do I specify my data?

: Model의 Data에서, 다른 부분집합들을 명시하기 위한 추상화. 위의 사진에서 Selections에 해당한다.

3) How do I change my data?

: Selections에서 수행될 수 있는 연산들을 표현하기 위한 추상화. 위의 사진에서 Commands에 해당한다.

 Model, Selections, Commands에 대한 이해를 돕기 위해, 예시를 들어 설명해보겠다. 아래의 그림을 보자. Model은 2차원 Integer Array라고 가정한다. View는 막대 그래프이다. Selections은 막대 그래프에 표시된 Data의 부분을 명시(또는 구분)할 수 있는 수단을 제공한다. Commands는 Data로 할 수 있는 동작들이다.

4. Presentation

4-1. Three User Interface Questions

: Application에서 UI를 어떻게 설계할 수 있을까? Taligent는 Data Management를 나눴던 것과 비슷하게, 3개의 질문을 바탕으로 3 부분으로 나누었다. 아래의 그림을 보자.

1) How do I display my data?

: 위의 그림에서 View에 해당한다. View는, 여러 개의 다른 View들로 구성될 수 있고 각 View들은 꼭 시각적으로 표시되지 않아도 된다.

2) How do events map into changes in my data?

: 위의 그림에서 Interactor에 해당한다.

3) How do I put it all together?

: 위의 그림에서 Presenter에 해당한다. Presenter는 MVC의 Controller와 유사하지만... 좀 더 높은, 추상화된 Application Level에 위치하고 Command와 Interactor랑 상호작용한다. 이 Presenter의 약자를 따서, Taligent가 제안한 Programming Model을 MVP(Model View Presenter)라고 이름을 지었다.

 Presenter의 역할을 좀 더 직관적으로 요약하면, Event를 받아서 적절한 Command에 연결해주는 것이라고 볼 수 있다(본 MVP를 소개하는 원문에서는, 이것을 Business Logic을 제공한다고 표현했다).

 이해를 돕기 위해 예시를 들어 설명해보겠다. 아래의 그림에서, Interactor에게 'Mouse Cursor의 이동'이나 'Menu의 선택'과 같은 행위를 적절한 Event로 정의할 수 있다. Interactor가 행위에 대한 Event를 전달하면, Presenter는 전통적인 Application의 'Main' 또는 'Event Loop'처럼 동작하여... 적절한 Model, Selection, Command, View, Interactor를 만들거나 상호작용한다(그림 5에는 방향성이 있는 것처럼 그려져 있으나, MVP의 원문에는 단방향성을 지켜야 한다같은 제약은 없었다).

5. Programming Model Frameworks

: Taligent에서 MVP Programming Model을 고안했을때, 그들은 Object-Oriented Frameworks로 설계 및 구현했고... 개발자들이 자신의 Application에 Customizing할 수 있게 했다(이후, Taligent에서 몇번의 Release를 거쳐 Framework를 제공했었고, Update 내역에 대해 적혀있었는데, 중요한 내용이 아니라고 생각하여 생략했다).

6. Programming Model Classes

: 아래 그림은 MVP Programming Model에 대한 Class Diagram으로, 앞서 이야기했던 Concept이나 Structure들을 잘 나타내고 있다.

 IModel, IView, ISelection, ICommand, IInteractor, IPresenter와 같은 MVP의 기본적인 Class들이 있다. 개발자들은 이 기본적인 Class들의 Subclass를 만들어서, 개발하면 된다(옛날에는 Interface 역할을 하는 Type의 이름 앞에 I를 붙였었다고 하고, 이 원문이 쓰여진지는 20년도 더 지났다. 당연히, 사용하는 언어의 Spec에 따라, Protocol이나 Interface 같은 것을 써도 상관없다).

 이 당시, 어지간한 Application들은 Interactor를 직접 구현할 필요가 없었다. IMenuInteractor, IButtonInteractor 같은 많이들 쓸법한 Interactor들이 이미 구현된 Open Class Library가 있었기 때문이었다.

7. Building An Application - Client / Server

: MVP Programming Model로, Client / Server Application을 구현하면 어떤 형태일까? MVP의 각 구성요소들이, Client와 Server중에 어디에 구현되어야 할지 결정해야 할 것이다. 보통, 전통적인 Client와 Server는 Presenter에 따라 나눌 수 있다. Model, Selection, Command는 Server에 속할 것이다. View, Interactor는 Client에 속할 것이다. 그러면, Presenter는 Client와 Server를 연결하는 역할이 될 것이다. 즉, Client와 Server 모두를 위한, 하나의 개념적인 Presenter가 존재하게 된다. 하지만 Presenter는 하나이므로 Presenter에 Client 관련 Code가 Server 관련 Code보다 많아지거나, 그 반대의 상황이 생길 수 있다. 

 Client, Server 각각을 MVP로 구현해보면 아래의 그림과 같은 형태가 될 것이다. Client에서 Model은 Server에서 가져와서 사용하는 Surrogate 또는 Proxy 형태가 될 수 있다. Server는 따로 View가 없고, Client에 있는 View를 갱신하는 형태가 될 수 있다. 여기서의 핵심은, Client / Server 모두를 MVP Programming Model로 구현할 수 있다는 것이다.

8. Benefits of Abstractions

: 원문이 쓰여지던 당시, 다양한 Application을 개발하는 데에 MVP Programming Model을 활용할 수 있었다. MVP Programming Model의 구성요소대로, Logic들을 구분하고 나누는 것은 어떤 이점이 있는 걸까?

 Model과 View를 구분하는 것은, View의 독립시킬 수 있다는 이점이 있다. 간단한 예를 들면... 서로 다른 계산기의 UI가 있더라도, 동일한 계산기 핵심 Logic을 사용할 수 있는 상황을 생각해볼 수 있다.

 Selection과 Model을 구분하는 것은, Model을 독립시킬 수 있다는 이점이 있다. Model을 독립하면... Data의 구조나 File Format을 변경하더라도, Application의 나머지 부분에서 Data를 어떻게 보여주고 다룰 것인지를 변경하지 않아도 된다.

 언급한 2가지 이점들은 역할을 잘 구분하여 얻을 수 있는 일반적인 장점들이다. 이 2가지 이점 외에도 MVP Programming Model에 있는 구성요소들 중, 인접한 구성요소들간에는 구분하여 얻을 수 있는 장점들이 더 있다.

 궁극적으로는 MVP Programming Model로 추상화하여 구현하면... Platform이나 표준이 다르더라도 많은 Code들을 추가적인 수정없이 사용할 수 있는, 호환성(Portability)을 높일 수 있다는 장점이 있을 것이다.

9. 읽은 후 생각 정리

: MVC 대비, Model은 Data와 Data Management로 나누어 졌다. View와 Controller(MVP에선 Presenter) 사이에, Event를 전달 및 변환과 관련된 역할을 하는 Interactor가 추가되었다. Model과 Controller 사이에도 Selection과 Command가 추가되었다.

 하지만 원문의 내용과 달리, 지금도 iOS MVP Architecture로 검색해보면... 구현하려는 기능, 해결하려는 문제를 오직 Model, View, Presenter 세개의 Component에 맞추어서 설명하는 글들이 많다. Selection, Command, Interactor에 대해서는 언급이 없다. 심지어 MVC Architecture에서는 View에 UIView만 속했는데, MVP Architecture에서는 View에 UIView, UIViewController 모두 속하는 것이 차이라고 설명하는 글들도 있다. 당연히 잘못된 내용이다.

 바로 위의 문단(8. Benefits of Abstractions)에 Platform간의 호환성 이야기가 나오는데, 이걸 MVC에도 적용해보면... Controller에선 View가 어떤 형태인지 함부로 가정하거나 제한을 두지 않아야 한다. View는 UIKit에 속하는 Class로 구현할 수도 있고, AppKit에 속하는 Class로 구현할 수도 있다. 심지어 Metal로 구현할 수도 있다. 그렇다면 당연히, Controller는 UIKit, AppKit 같은 것에 의존적이지 않는 것이 바람직하다. 구현 편의상 UIViewController에 Controller의 역할을 부여하는 것은 이해가 되고 그것을 비판할 생각은 없지만, 그건 이상적인 Code가 아니라고 말하고 싶다.

 MVC의 이야기를 하며 글을 마무리 짓게 되었다. 빠른 시일내에, MVVM에 대해서도 정리해서 올려야지...

10. Reference

1) Mike Potel: MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java, Taligent Inc, 1996