MVC 패턴

목차

• MVC
• P of EAA 속 MVC
• MVC 창시자의 MVC
• 정리
• 한계

 

개요

이전에 프로젝트가 끝나고 잡담을 하던 중 옆에서 MV 뭐시기 패턴을 써서 협업하기 쉽게 해볼까 라는 얘기를 들은 적이 있습니다. 무슨 얘기인지 궁금해서 물어보고 당시에는 제대로 이해가 안되서 이후 MVC 패턴을 찾아보았습니다. 하지만 M, V, C간의 상호작용  내용이 미묘하게 다르게 설명하는 글이 많아 혼란스러워서 나름대로 답을 찾기 위해 패턴의 역사를 알아보려고 작성했습니다.

 

MVC

 

- P of EAA 

Model - View -Controller 아키텍처 패턴은 사용자 인터페이스 상호 작용을 세 가지 역할로 나눕니다.
1970년대 후반 Trygve Reenskaug가 Smalltalk 플랫폼을 위해 개발한 프레임워크로 시작되었으며,
가장 많이 인용되고 그와 동시에 가장 많이 잘못 인용된 패턴 중 하나입니다.
Patterns of Enterprise Application Architecture 330p .(Martin Fowler, .. 2002)

사용자의 인터페이스 상호작용을 3가지 역할로 나눕니다.

MVC 패턴은 3가지 역할로 나뉩니다.

1. Model : Model은 어떤 영역(도메인)에 대한 일부 정보를 나타내는 nonvisual object입니다. UI에 사용된 것 이외의 모든 데이터와 행동을 포함하고 있습니다.

2. View : UI에서 모델을 표시하는 것을 뜻합니다. 예를들어 Model이 고객 개체라면 UI는 Model의 정보로 렌더링된 HTML페이지일 수 있습니다. View는 오직 정보에 대한 UI 표시일 뿐이며, 정보에 대한 모든 변경은 Controller가 처리합니다.

3. Controller : 사용자 입력을 받아 Model을 조작하고 View가 적절하게 업데이트 되도록 합니다. 로직까지 생각하면 UI는 View와 Controller의 조합입니다.

저자는 MVC에 표시(*Presentation)을 모델에서 분리, Controller를 View에서 분리하는 2가지 중요 분리점이 있다고 합니다. 특히 표시를 모델에서 분리하는 것은 좋은 소프트웨어 디자인의 가장 기본적인 휴리스틱 중 하나라고 합니다. 
[*Presentation : View와 Controller를 포함해 UI에 표시를 지칭하는 것으로 보입니다.]

 

프레젠테이션을 모델에서 분리 이유

● 기본적으로 프레젠테이션과 모델은 관심사가 다릅니다. 프레젠테이션를 개발할 때 UI 매커니즘과 좋은 사용자 인터페이스 배치를 고려하지만, 모델과 작업할 때는 데이터베이스 상호작용, 비즈니스 정책 등을 고려할 것입니다. 또한 각 부분은 전혀 다른 라이브러리를 사용할 것입니다. 일반적으로 한 영역에 하나의 측면을 전문적으로 하는 것을 선호합니다.

● 상황에 따라 사용자는 동일한 모델 정보를 다른 방식으로 보고 싶어합니다. 예를들어 시험성적을 보고 싶을 때 단순히 점수를 보고 싶을수도, 그래프로 보고 싶을 수도 있습니다. 프레젠테이션/뷰를 분리하면 여러 프레젠테이션을 개발하며 완전히 다른 인터페이스를 사용하면서도 동일한 모델 코드를 사용할 수 있습니다.(그래서 모델과 뷰는 여러 관계를 가질 수 있습니다)

● 일반적으로 nonvisual object는 visual object보다 테스트하기 쉽습니다.
이 분리의 핵심은 종속성의 방향입니다. 즉, 프레젠테이션는 모델에 따라 다르지만 모델은 프레젠테이션 따라 달라지지 않는다는 점입니다. 모델에서 작업하는 사람들은 어떤 프레젠테이션이 사용되고 있는지 완전히 모르는 상태로 의식하지 않아야 합니다. 이는 작업을 단순화하고 새로운 프레젠테이션를 더 쉽게 구축하며, 모델을 변경하지 않고도 프레젠테이션을 자유롭게 변경할 수 있어야 한다는 것을 의미합니다.

visual과 nonvisual object에 분리는 가장 중요한 설계 원리입니다.

 

뷰와 컨트롤러의 분리 이유

뷰와 컨트롤러의 분리는 비교적 덜 중요합니다. 실제로, 거의 대부분에 Smalltalk 버전에서 View와 Controller를 분리하지 않았습니다. 

뷰와 컨트롤러를 분리하려는 대표적인 이유는 편집 가능한 동작과 불가능한 동작을 분리해 지원하기 위해서입니다.
하나의 뷰에 대해 2개의 컨트롤러를 둠으로 해결할 수 있으며, 이때 컨트롤러들은 뷰를 위한 전략패턴[GoF]입니다.
대부분의 시스템에서는 뷰당 하나의 컨트롤러만 있기 때문에 이러한 분리는 일반적으로 수행되지 않지만, 웹 인터페이스에서 이 방법이 인기를 얻으며 유용하게 사용되고 있습니다.

뷰와 컨트롤러의 분리는 정말 도움이 될 때만 하는 것이 좋습니다. 

 

 

- Trygve M. H. Reenskaug 

The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer.
MVC was conceived as a general solution to the problem of users controlling a large and complex data set. 
*(출처) https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-index.html

MVC는 인간이 프로그램을 바라보는 관점과 프로그램 모델 사이 거리를 이해하기 쉬운 구조로 좁혀 GUI 애플리케이션에 어울리는 설계를 고민하는 것에서 시작됐습니다.

Model : 모델은 지식/정보를 나타냅니다. 이는 단일 객체일 수 있고 혹은, 객체들의 구조일 수 있습니다.

View : 뷰는 모델의 (시각적, visual) 표현입니다. 뷰는 모델에 첨부되어있으며, 질문을 통해 모델로부터 프레젠테이션에 필요한 데이터를 얻습니다. 또한 적절한 메시지를 전송해 모델을 업데이트할 수도 있습니다. 따라서 뷰는 모델이 나타내는 모델의 속성의 의미를 알아야 합니다.

Controller : 컨트롤러는 사용자와 시스템 사이 링크입니다. 컨트롤러는 뷰를 보충해서는 안되며, 반대로 뷰는 마우스 조작과 같은 사용자 입력에 대해 절대 알 수 없어야 합니다.

(*Models-View-Controllers. 10.Dec.1979)

 

 

정리

MVC 패턴은 화면을 프레젠테이션할 때 필요한 기능을 3가지 역할로 나눠 분리하여, 관심사를 분리한 것으로 보입니다.
그 분리점을 가장 근원적인 관심사/책임(Visual vs NonVisual)으로 분리할수도, 동작을 관점으로 분리할 수도 있습니다.

특히 이 시기(1972년)에는 입력을 처리하는 과정이 복잡했기에 책임을 Controller로 분리해야 했다고 합니다.

결국 핵심은 관심사를 어떻게 분리했냐에 관점(Separation of Concerns)이라 생각합니다. 인터페이스에 무언가 띄어주기 위해서 직관적으로 관심사가 나뉘어 있기에 웹에서도 유행했었다 생각합니다.

Model의 변경을 옵저버 패턴으로 감시하고, 변경 감지 시 자신을 변경하도록 구현하거나 Controller가 변경해주거나 등 구현은 다양한 것 같습니다.

한계

1. Massive해지는 Controller

Model과 View 사이 의존성을 없앨 수 없습니다. Model과 View와 연결된 Controller에서 주로 의존성을 해소한다는데 자연스럽게 Model과 View가 많아질수록 Controller가 무거워진다고 합니다. 

2. 단위/유닛 테스트가 어렵다.

위 프레젠테이션과 모델을 분리할 때도 나온 것처럼 실질적인 View와 연관된 부분은 테스트가 어렵다고 합니다.

앱 어플리케이션 프로젝트에서는 View와 연관된 부분들은 테스트가 까다롭고
테스트 대비 얻는 이익이 크지 않기 때문에 진행을 하지 않는 경우가 많습니다.
MVC에서 테스트는 M 까지가 용이합니다. 여러 Utils, Services, Helpers 등이 테스트 대상입니다.
만약 모델 레이어의 테스트가 용이하지 않다면 설계의 문제가 있을 가능성이 있습니다.
MVP는 M, P가 테스트 대상인데 Presenter에서는 추상화된 View에 접근하기 때문에 테스트가 가능합니다.
MVVM은 M, VM이 테스트 대상인데 ViewModel은 View와 독립적이며 바인딩으로 연결되기 때문에 테스트가 쉽습니다.
*(출처) https://jisoo.net/2018/11/24/why-mvc-destroyed.html

MVP 패턴은 MVC 패턴의 파생으로, Controller를 View와 1:1관계로 제한하며, 뷰와 컨트롤러의 분리를 확실하게 나눈 것으로 생각됩니다. → MVP 패턴 확인 필요. 

기존 MVC가 대부분 뷰와 컨트롤러를 분리하지 않아 M / VC로 나뉘어 View에 대한 테스트가 힘들었다면,
MVP, MVVM에 경우 View와 다른 영역에 분리가 필수적으로 진행되어 자동화된 단위 테스트가 가능하게 된 것 같습니다.

* 참고 출처

Patterns of Enterprise Application Architecture(Martin Fowler, 2002.11.05)

 

https://jisoo.net/2018/11/24/why-mvc-destroyed.html

iOS에서 MVC는 왜 망가질까

 

https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-index.html

Trygve/MVC