[펌] MVC 패턴과 확장 (MVC, MVP, MVVM)

출처  : http://blog.naver.com/kkpa1002/20115983343   : http://maskkwon.tistory.com/category/Programming/Pattern

패턴들을 자세히 살펴보면, 패턴 내의 컴포넌트들과 그것들의 관계가 항상 '원자적(atomic)'이지만은 않다는 것을 알수 있다. 어떤 문제를 해결하기 위해서는 패턴 내의 컴포넌트가 서로 밀접하게 상호작용해야 하며, 문제의 성격이나 그 문제가 발생한 상황에 따라 컴포넌트의 결합이 불가피할 수도 있기 때문이다. 이것은 패턴간의 관계에서도 마찬가지다. 패턴을 통해 어떤 문제를 해결하기 위한 과정에서 또다른 문제가 야기되기도 하고, 그 문제를 또 다른 패턴으로 해결할 수도 있기 때문이다. 이런 점들을 통해, 특정 패턴 내에 있는 컴포넌트들이나 그것들의 관계는 더 작은 패턴에 의해 서술될 수 있으며, 그것들을 포함하고 있는 더 큰 패턴에 통합될수도 있다는 것을 알수 있다. 실제로도 이런 패턴들은 변형되고 일반화되어 새로운 형태의 패턴으로 발전하기도 한다. [POSA1] 여기서는 가장 널리 알려진 패턴중 하나인 MVC(Model-View-Control)패턴과 그로부터 파생된 패턴들의 관계에 대해 다뤄보도록 하겠다.   ― 이 글의 목적은 MVC 패턴과 그로부터 파생된 패턴들의 관계를 설명하는데 있다.   여기서 언급되는 각 패턴의 세부 내용은 다음기회에 다루도록 하겠다. ―   MVC(Model-View-Control) 패턴 MVC 패턴은 애플리케이션을 '프로세싱(processing)', '출력(ouput)', '입력(input)'의 세 개 영역으로 분리한다. MVC 패턴에서는 각 영역을 Model, View, Controller라는 컴포넌트로 표현하는데, 각 컴포넌트가 담당하는 일을 정리하면 다음과 같다. - Model : 데이터와 그 처리 로직(logic)을 가지고 있다. - View : 실제 UI요소를 그려준다. - Controller : 사용자의 입력 정보를 이벤트(event) 형태로 수신한다.       여기서 Model은 특정 출력 표현방식이나 입력 동작에 영향을 받지 않고 독립적이며, View는 Model로부터 데이터를 얻는다. View는 각각 하나씩의 Controller와 연결되는데, Controller는 Model과 View에 수신한 이벤트를 처리하는 서비스를 요청한다.[POSA1][GoF] MVC 패턴의 변형 이 글에서는 아래 그림과 같이 MVC 패턴의 변형을 시스템 구성 관점과 UI 구조 관점에서 다룰 것이다.           이어 소개할 PAC 패턴은 MVC 패턴에 기반을 두고, 시스템 구성 관점으로 발전시킨 패턴이며, Document-View, MVP, MVVM 패턴은 모두 UI 구조 관점에서 MVC 패턴을 발전시킨 패턴이다.         PAC(Presentation-Abstraction-Control) 패턴 PAC 패턴은 MVC 패턴을 시스템 구조적 관점으로 변형한 패턴이다. PAC 패턴에서는 계층구조(hierarchy)를 이룬 에이전트(agent)들이 서로 협력·상호작용하는 소프트웨어 시스템의 구조를 형성한다. PAC 패턴의 특징과 MVC 패턴과의 차이점을 그림으로 표현하면 다음과 같다.   PAC 패턴을 통해 구성하는 것은 특정 수준의 기능을 담당하는 에이전트이다. 각 에이전트를 구성하는 요소는 다음과 같은 세가지 컴포넌트이다. - Presentation : 사용자에게 노출되는 UI요소를 그려준다. - Abstraction : 해당 에이전트에서 처리할 데이터와 그 처리 로직를 가지고 있다. - Control : 사용자 UI와 데이터를 연결하고, 다른 에이전트와의 상호작용을 수행한다. 각 에이전트는 Control 컴포넌트를 통해 다양한 수준의 다른 에이전트와 상호작용하게 된다. 이런 구성은 시스템-시스템간의 상호작용과 사람-시스템간의 상호작용을 분리시킬 수 있도록 한다. [POSA1]       Document-View 패턴 Document-View 패턴에서는 아래 그림과 같이 MVC 패턴의 View와 Controller의 분리를 완화한다.       대부분의 GUI 개발 환경에서 창 디스플레이(display)와 이벤트 핸들링(event handling)은 밀접하게 얽혀있다. 이런 점 때문에 Document-View 패턴에서는 View 컴포넌트에 MVC패턴의 View와 Controller의 역할을 조합해 놓았다.   단, 이런 경우에는 Controller의 교환 가능성(exchangeability)을 희생해야 한다. Document-View 패턴을 구성하는 컴포넌트와 역할을 정리하면 다음과 같다. - Document : 데이터와 그 처리 로직을 가지고 있다.               MVC 패턴의 Model과 동일한 역할을 수행한다. - View : 사용자의 입력정보를 수신하고, UI요소를 그린다.            MVC 패턴에서 언급되는 View와 Controller의 역할을 동시에 수행한다. MVC 패턴에서와 마찬가지로 Document-View 패턴에서도 Document와 View가 느슨하게 결합(loosly coupled)된다. [POSA1]       MVP(Model-View-Presentation) MVP 패턴은 Document-View 패턴의 View 영역을 개선한 패턴으로 크게 Model-View-Presenter 세 개의 컴포넌트로 구성된다. 패턴을 도식화하면 밑의 그림과 같다. MVC의 View에 남아있는 모든 비지니스 로직을 전부 Presenter로 통합 했다는데에 있다. 이는 MVC에서 View와 Controller에 조금이나마 남아있던 결합도 마저 낮추게 된다. 결국 같은 View를 사용하더라도 이에 연결된 Presenter의 로직에 관하여 완전히 다른 로직을 구현할 수 있게 됨으로써 유지/보수의 편리를 추구하는 패턴이다.            MVP 패턴에서는 아래 그림과 같이 Document-View 패턴에서의 View 를 View 와 Presenter로 분리한다. MVP 패턴을 구성하는 각 컴포넌트가 담당하는 일은 다음과 같다.             - Model : 데이터와 그 처리 로직을 가지고 있다. 즉, 애플리케이션의 정보(데이터)를 나타낸다. - View : 실제 UI 요소를 그려준다. 즉, 사용자 인터페이스 요소를 나타낸다.  - Presenter : View와 Model간의 상호작용을 담당한다. (MVC의 Controller와 비슷하지만 명백한 차이점이 있다.)                 MVP 패턴의 핵심 목표는 View와 Model간의 결합도를 낮추는 데 있다.       여기서는 Presenter가 Model 의 데이터를 View에 출력할 수 있도록 할 뿐만 아니라 이벤트를 View에서 받아 Model의 데이터를 갱신하기도 한다. 실제 구현에서는 Presenter는 View와의 결합도를 감소시키기 위해서 View를 직접 참조하는 대신 View의 Interface를 참조한다. 이를 통해 Presenter 는 View의 실제 UI 요소가 어떻게 구현되는지에 관계없이 데이터를 올바르게 표현하도록 할 수 있다. [MSDN]       MVVM(Model-View-ViewModel) MVVM 패턴은 아래 그림과 같이 사용자와의 상호통신이 활발하고 동적인 사용자 인터페이스를 가지는 클라이언트 응용프로그램에게 적합하도록 MVP패턴을 개선한 패턴이다.   간단히 말해 MVVM은 Controller 대신에 View Model을 사용하는 것이다. UI 플랫폼이 발달하면서 UI에 관한 데이터와 커맨드는 다양하고 복잡해지기 시작했다. Controller와 Model보다 View의 비중이 높아지면서 각 View의 데이터와 커맨드를 모두 가지고 있는 View Model을 사용하게 된것이다. View Model을 이용하고 각 View의 커맨드와 데이터를 각 View Model이 가지게 되면서 개발이 더욱 직관적으로 바꼈다. 또한 Controller와 Model과의 연관 관계를 최소화 시켜 결합도를 낮추는데 기여하는 패턴이다.         MVVM 패턴을 구성하는 각 컴포넌트가 담당하는 일을 정리해보면 다음과 같다. - Model : 데이터와 그 처리 로직을 가지고 있다. - View : 사용자의 입력정보를 수신하고, UI요소를 그린다.          MVP 패턴에서 언급되는 View와 Presenter의 역할을 모두 포함한다. - ViewModel : View에서 보여줘야 할 데이터와 수정에 필요한 로직을 가지고 있다. MVVM 패턴이 가장 활발하게 사용되는 분야가 WPF(Windows Presentation Framework) 개발 분야인데 WPF의 예를 구조화하면 다음 그림과 같다.     WPF에서 UI를 만들면 코드 비하인드(Code-Behind)와 XAML이 쌍으로 생성된다. 일반적으로 XAML에서는 각 디자인 요소에 이름을 주고, 그 이름에 따라 코드 비하인드에서 각종 처리 코드를 작성해야 한다.   이 경우, 추후에 디자인 요구사항이 변경되면 변경된 XAML파일에 맞게 개발 코드를 일일히 수정해야 하는 문제가 있다. MVVM 패턴에서는 View를 XAML과 코드 비하인드의 쌍으로 본다. 그리고 Model은 시스템에서 처리해야 할 데이터와 그 처리 로직을 의미한다. 이 View와 Model은 서로 독립적이며 연관성도 없다.   다만 중간에 ViewModel을 두어 Model의 데이터가 생성되거나, 변경 되었을 때 바인딩(binding)으로 엮여 있는 View의 값을 변경시켜주는 역할을 한다. ViewModel과 View는 바인딩 방식으로 데이터를 주고 받기 때문에, ViewModel은 View를 구성하고 있는 객체 이름과 독립적으로 만들어질 수 있다. [MSDN]   MVC, MVP, MVVM 의 이해 Model 과 View 그리고 서로간의 관계 오늘 설명할 프레임워크들에서 변하지 않는 공통적인 용어 두개의 일반적 의미부터 짚고 넘어가 보자. Model 모델은 도메인 개체 그 자체이다. 도메인은 프로그램 내에서 동일한 의미를 갖는 대상이다. 보통 Data 그 자체와 동일시 되지만, 이 외의 데이터를 조작할 수 있는 기능이 추가되기도 한다.  구현과 상황에 따라서는 단순히 데이터소스에 접근하는 DAO 역할을 하거나,  파일 시스템 자체가 되거나, 라이브러리 세트가 된다. View 디스플레이. 사용자(Client. 사람이 아닌 기계 혹은 동물일수도 있다. 어플리케이션이 이용되는 타겟이라고 생각하자) 에게 제공되는 UI Layer를 말한다. 더욱 큰 의미를 포함하면 눈으로 이미지가 곁들여지거나 글자로 이루어지지 않은 바이트 코드의 나열이나 음악 파일등이라도, Client 가 이해할 수 있다면 View가 될 수 있다. 보통 Web Application 등에서는 View는 HTML/CSS 로 렌더링된 화면을 가르킨다. 둘의 관계.. MVC를 비롯한 여러 프레임워크들이 나온 이유는 명확하다. 각 계층의 분리로 재활용성을 높이고 중복을 막자는 것이다. 각 계층의 강한 결합이 발생한다면 애초에 프레임워크를 적용하는 의미가 없다. 이 둘의 의존성을 어떻게 제어하느냐에 따라 MVC, MVP, MVVM … etc 등으로 나뉘게 된다.   Controller, Presenter, ViewModel…? mvc-mvp-mvvm.png       Controller 모든 입력은 Controller에서 처리된다. 특정 입력이 들어오면 Controller는 그 입력에 해당하는 Model을 선택하여 처리하게 한다. Controller는 입력에 따라 Model을 업데이트하고, 결과에 따라 다른 View를 선택한다. Controller는 View를 선택할 수 있기에 View를 여러개 관리할 수 있다. 일반적으로 View는 Model을 사용하여 업데이트를 하지만, Model을 관리하는 것은 Controller이므로 사실상 View는 Model을 직접적으로 생성하거나 관리하는 것은 아니다. Model을 이용하거나 이용될 뿐이다. Controller는 Model을 조작하고 View를 선택하지만 View를 직접 업데이트하진 않는다. 이 경우에는 View와 Model의 관계가 어느정도 있으며 View가 Model을 직접 사용하여 업데이트가 되거나, 아니면 Model은 자신과 관련돤 View 들에게 Notify 해줘서 View가 업데이트 되는 방식도 있고, View가 polling 을 통해 Model의 변화를 알아채고 스스로 업데이트하는 방식도 있다. 어느것이 되었든 View와 Model의 어느정도의 의존성은 피할 수 없다. 이것이 Controller를 사용하는 MVC의 문제점이라면 문제점이다. MVC 패턴의 좋은 구성은 최대한 이 둘의 의존성을 낮추는게 관건이다. 조금 억지스러운 예를 들어보자. View와 Model이 클럽에 온 소극적인 남녀라면 Controller는 이 둘을 부킹해주는 실력좋은 웨이터이다. 여기서 소극적인 이라는게 중요하다. 물론 웨이터는 수 많은 요청에 의해 오늘도 매번 부킹에 성공할 것이다. Presenter View와 Model 사이의 상호작용을 담당한다. 또한, 이 경우 사용자의 입력 처리는 Controller 가 아닌 View가 담당한다. V iew가 이벤트를 Presenter에 전달하면 이벤트에 맞춰 Presenter는 Model을 조작하고 그 결과를 다시 View에 바인딩하여 View의 요소들이 업데이트된다. Controller는 단순히 View를 선택하고 Model을 조작한 뒤 실제 회면 갱신은 View와 Model의 상호작용으로 이루어지지만 Presenter 를 사용한 MVP에서는 Presenter가 Model을 조작하고 관리하며 변경이 있으면 Model에 따라 View를 업데이트하게 된다. 실제 구현체로 생각해본다면 Presenter는 Model과 View의 인스턴스를 모두 가지고 있어야 할 것이다. View가 섬이고 Model이 육지라면 그 사이를 이어주는 다리와 같다고 보면 될 듯 싶다. View와 Presenter는 1:1 관계로 맺어지며 Presenter는 보통 Model보다는 View에 더 닮은 구조로 디자인된다. MVC와는 다르게 View와 Model의 관계가 전혀 없으며 단지 View는 Presenter라는 것을 하나씩 가지고 있게 된다. 그리고 입력 처리를 View에서 처리한다는 점도 큰 차이점이 된다. 이 녀석을 사용하면 View와 Model의 의존관계가 완전히 없어진다. ViewModel View의 표현을 담당한다고 보면 되겠다. MVP와 매우 비슷하지만 큰 차이점이라면 비중이 View에 좀더 치우쳐 있다는 점이며, Presenter는 View에 상당한 의존성이 있었지만, Controller, Presenter의 위치인 ViewModel은 View와 아무런 관련이 없다. 여러 View들은 하나의 ViewModel을 선택하여 바인딩하고 업데이트를 받는다. ViewModel의 디자인은 View보다는Model에 비슷하게 구성된다.  보통 ViewModel이 변경되면 자동으로 View에 업데이트되는 방식으로 구현된다. Model이 순수한 Model이라면 ViewModel은 View를 위한 모든 커스터마이징을 제공하는 Model이다. 좀 억지를 부려보면, ViewModel이 회사라면 View는 근무하는 사원에 가깝다. 회사는 사원의 여러 근무에 대한 환경을 제공한다. 이윤을 위해서라면 회사는 그 무엇과도 거래하고 연결한다.   MVC (Model - View - Controller) - Controller 에 직접 Input - View 와 Controller : Many to one 관계 - View 는 Controller 를 참조하지 않음 - Model 은 View 를 간접적으로 참조함 - > Controller 에 입력이 들어오면 Controller 는 Model 에 있는 Data 를 조작하고, View 는 Model 에서 조작된 data 를 참조하여 View 를 수정한다. 이 때 View 가 Model 을 참조하거나 Model 이 View 를 참조하거나 하는 방식으로 변화에 대한 업데이트를 할텐데 결국 View 와 Model 이 참조를 할 수 밖에 없다는 이야기. MVP (Model - View - Presenter) - View 에 직접 Input - View 와 Presenter : one to one 관계 - View 는 자신의 Presenter 를 참조하고 Presenter 역시 View 를 알고 있음 - View 는 Model 를 참조하지 않아 Presenter 를 통해 Model 을 업데이트함 -> View 에 입력이 들어오면 Presenter 에 data 를 요청하고, Presenter 는 자신이 참조하는 Model 에 업데이트를 요청하는 방식으로 동작한다. 이 경우 View와 Model 은 완벽히 분리되지만 View 와 Code 가 완벽히 분리됐다고 보기는 어렵다. MVVM (Model - View - ViewModel) - View 에 직접 Input - View 와 ViewModel : Many to one 관계 - ViewModel 은 View 를 참조하지 않음 - View 는 Model 를 참조하지 않아 ViewModel 를 통해 Model 을 업데이트함 -> View 에 입력이 들어오면 View 가 참조하고 있는 ViewModel 에서 Binding 된 객체를 찾아 업데이트를 한다. MVP 패턴에서는 Presenter 는 전적으로 View 의 형태에 따라 달라지지만, MVVM 패턴에서는 ViewModel 이 View 를 참조하지 않으므로 Model 의 형태를 따른다고 할 수 있다. View 는 Model 과 완벽히 분리되며 ViewModel 과도 Binding 을 통해 자동 업데이트 되므로 data 와도 완벽히 분리된다

결론

정리하고보니 더욱 애매한 것 같다. 더욱이 패턴의 개념은 구현에 따라 조금씩 변하고 달라지기에 이 셋을 완전히 구분해서 완벽히 이해한다는것도 쉽지 않은 일이다.

더구나 글의 서두에서 밝혔듯이 Model, View의 개념만으로도 개발자들은 제각각의 생각과 구현을 갖고 있을 수 있다.
게다가 만일 이 셋보다 더 획기적인 것이 등장한다면 새로운 용어와 함께 새로운 개념을 이해하려고 시간을 보내고 무슨차이가 있는지 고민이 늘어날 것이다.

이 셋의 차이점을 줄줄 외우는 것보다 이러한 개념의 구분이 어떠한 장점이 있으며, 뭐가 현재 상황에 더 적합한지를 파악하고 사용하는 것이 더 좋을 것 같다.

 

참고자료

• http://www.codeproject.com/Articles/42830/Model-View-Controller-Model-View-Presenter-and-Mod
• http://tomyrhymond.wordpress.com/2011/09/16/mvc-mvp-and-mvvm/
• http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/
• http://geekswithblogs.net/dlussier/archive/2009/11/21/136454.aspx
• http://msdn.microsoft.com/en-us/magazine/hh297451.aspx
• http://russelleast.wordpress.com/2008/08/09/overview-of-the-modelview-viewmodel-mvvm-pattern-and-data-binding/
• http://frends.kr/post/knockout-dot-j-s-sogae/ Knockout.js

 

mvc-mvp-mvvm.png

0.06MB