본문 바로가기
CS/디자인패턴

[디자인 패턴]MVC, MVP, MVVM 패턴 비교

by 새파란레몬 2024. 2. 18.

 

일하는 곳에서 MVVM 패턴을 새롭게 익히게 되어, 이와 관련한 개념을 정리해보려 블로그를 작성하게 되었습니다. 

 

우선은 디자인 패턴이란, 소프트웨어 설계에서 발생하는 공통적인 문제들에 대한 해결책으로, 시간이 지나면서 발전해온 어떤 문제 해결 솔루션입니다. 저는 이런 방식이 일종의 관습법과 맥락을 같이 한다고 느꼈습니다.

 

관습법 또한 어떤 공식적인 입법절차보다, 사람들간에 가장 좋다고 생각한 방식이 합의에 이르러 오랜 기간 걸쳐 굳어져 온 것이기 때문입니다.

 

그 중 대표적인 디자인 패턴은 MVC가 있고 이번에 전 추가적으로 MVP와 MVVM 패턴을 알게 되었습니다. 

 

이번 포스팅에서는 각 패턴의 역사적 배경과 어떤 기술적 한계를 극복했는지, 각각 어떤 역할이 어떤 방식과 순서로 작동하는지와 마지막으로 비유를 통해서 설명해보고자 합니다. 

 

역사적 배경 & 기술적 한계

 

1. MVC

해당 패턴은 1970년대 후반에 등장하여 초기 웹 애플리케이션 개발에 많이 사용 되었습니다. 이 애플리케이션은 모델(Model), 뷰(View), 컨트롤러(Controller)의 세 부분으로 분리하여 개발하는 방법을 제공하여 개발 과정에서의 역할 분담을 명확히 하는 데 기여했습니다. 이에 따라 애플리케이션의 유지보수성의 크게 향상되었습니다. 

 

하지만 웹 애플리케이션이 점점 복잡해져, 뷰와 모델 사이의 동기화 문제와 컨트롤러의 과중한 책임이 문제가 되었습니다. 

 

2. MVP

따라서 MVC의 변형으로 MVP가 1990년대에 등장하였습니다. MVP에서는 프레젠터(Presenter)가 뷰(View)와 모델(Model) 사이의 상호작용을 중재하게 됩니다. 따라서 뷰와 모델간의 직접적인 의존성을 제거해 뷰의 테스트가 용이해지고, 뷰의 로직을 단순화 할 수 있게 했습니다.

 

하지만 그에 따라 이전의 복잡성을 프레젠터가 이어받아 이번에는 프레젠터의 복잡성이 증가하게 되었습니다.  

 

3. MVVM 
이 패턴은 초반의 마이크로소프트에 의해 WPF(Windows Presentation Foundation)와 함께 소개되었습니다. 

MVVM의 두드러지는 특징은 뷰(View)와 뷰 모델(ViewModel) 사이의 양방향 데이터 바인딩을 통해, 사용자 인터페이스의 자동 업데이트를 가능하게 하는 것입니다. 이로 인해 뷰의 코드가 최소화할수 있고, 뷰 모델이 뷰의 상태와 로직을 관리함으로서 UI개발의 생산성과 테스트 용이성을 향상시켰습니다.

 

하지만 데이터 바인딩의 복잡성과 디버깅의 어려움이 단점으로 지적됩니다.

 

 

WPF & 데이터 바인딩 기술 이란?

WPF(Windows Presentation Foundation)란?

WPF는 마이크로소프트가 Windows Vista와 함께 도입한 사용자 인터페이스 프레임워크입니다. .NET 프레임워크의 일부로, 데스크탑 애플리케이션에 대한 풍부한 사용자 인터페이스(UI)를 구축할 수 있게 해줍니다. WPF는 XAML(eXtensible Application Markup Language)을 사용하여 UI를 선언적으로 구성할 수 있게 하며, 2D 및 3D 그래픽, 애니메이션, 스타일링, 데이터 바인딩 등 고급 UI 기능을 제공합니다.도입 배경: 이전의 UI 개발 방식인 WinForms가 제공하는 UI 구성 요소와 유연성의 한계를 극복하고, 더 풍부하고 동적인 UI를 쉽게 구축할 수 있도록 하기 위해 WPF가 도입되었습니다. WPF는 애플리케이션의 UI와 로직을 분리할 수 있게 하여, 개발자와 디자이너 간의 협업을 용이하게 합니다.

데이터 바인딩 기술이란?

데이터 바인딩은 UI 컴포넌트(예: 텍스트 박스, 리스트)와 데이터 소스(모델) 사이의 연결을 자동으로 설정하는 기술입니다. 이를 통해, 데이터 소스의 값이 변경될 때 UI 컴포넌트가 자동으로 업데이트되며, 반대로 사용자 인터페이스에서의 변경사항이 데이터 모델에 자동으로 반영됩니다. WPF에서 데이터 바인딩은 XAML과 함께 사용되어, 복잡한 데이터 관계를 쉽게 관리하고, 코드 비하인드를 최소화하여 애플리케이션의 유지보수성을 향상시킵니다.

 

 

 

 각 모델의 구성과 작동 방식


 

MVC (Model-View-Controller)

  • Model: 데이터와 비즈니스 로직을 관리합니다. 사용자의 요청에 따른 데이터의 처리와 저장, 데이터 변경에 대한 정보를 View와 Controller에 제공합니다.
  • View: 사용자에게 UI를 통해 정보를 표시합니다. Model로부터 데이터를 받아 사용자에게 보여주는 포맷을 관리합니다.
  • Controller: 사용자의 입력을 받고 처리합니다. 사용자의 액션에 따라 Model을 업데이트하고, 그 결과를 바탕으로 View를 다시 렌더링합니다.

작동 방식:

  1. 사용자의 액션은 Controller를 통해 받아들여집니다.
  2. Controller는 Model을 조작하거나 상태를 변경합니다.
  3. 변경된 Model은 새로운 데이터를 View에 제공합니다.
  4. View는 최신 데이터로 UI를 업데이트합니다.

MVP (Model-View-Presenter)

  • Model: MVC와 마찬가지로 데이터와 비즈니스 로직을 관리합니다.
  • View: 사용자 인터페이스를 담당합니다. 하지만 MVP에서는 Presenter를 통해 모든 사용자 입력을 처리하도록 합니다.
  • Presenter: View로부터 사용자의 입력을 받아 Model을 업데이트하고, Model의 변경 사항을 View에 반영하여 UI를 업데이트합니다.

작동 방식:

  1. View는 사용자의 입력을 Presenter에게 전달합니다.
  2. Presenter는 이 입력을 기반으로 Model을 업데이트하고, 결과를 View에 반영합니다.
  3. View는 Presenter로부터 받은 데이터로 UI를 업데이트합니다.

MVVM (Model-View-ViewModel)

  • Model: 데이터 처리와 비즈니스 로직을 담당합니다.
  • View: 사용자에게 UI를 통해 정보를 표시합니다. MVVM에서는 View가 ViewModel을 구독하고, ViewModel의 상태 변화에 반응하여 UI를 업데이트합니다.
  • ViewModel: View를 위한 Model의 추상화입니다. View에 표시될 데이터와 명령을 관리하며, Model과 View 사이의 데이터 바인딩을 처리합니다.

작동 방식:

  1. 사용자의 액션은 View를 통해 받아들여지고, ViewModel에 정의된 명령을 트리거합니다.
  2. ViewModel은 필요한 경우 Model을 업데이트하고, 자신의 상태를 변경합니다.
  3. View는 ViewModel의 상태 변화를 감지하고, 데이터 바인딩을 통해 자동으로 UI를 업데이트합니다.

 

 

비유를 통해 이해해보는 패턴 간 차이점


 

이제는 비유를 통해서 설명해보겠습니다. 

저는 각각의 패턴이 국가 간의 무역에 비유해 볼 수 있다고 생각했습니다.

 

먼저 각 패턴의 역할이 국가간 무역에 어떤 위치에 있을지 써보겠습니다.

MVC 패턴

 

모델(Model) = 생산국: 모델은 애플리케이션의 데이터와 비즈니스 로직을 처리합니다. 이를 생산국에 비유할 수 있습니다. 생산국에서는 다양한 상품과 서비스(데이터 및 로직)를 생산합니다.

뷰(View) = 소비자: 뷰는 사용자에게 정보를 표시합니다. 이는 소비자에 비유될 수 있습니다. 소비자는 생산된 상품을 사용하거나 소비하는 역할을 합니다. 뷰는 사용자가 필요로 하는 정보를 시각적으로 소비합니다.

컨트롤러(Controller) = 무역상: 컨트롤러는 사용자의 입력을 받아 모델을 업데이트하고, 그 결과를 뷰에 반영합니다. 이 과정은 무역상이 생산국으로부터 상품을 수입하여 소비자에게 판매하는 과정에 비유할 수 있습니다. 무역상은 생산국(모델)과 소비자(뷰) 사이에서 상품의 흐름을 조정합니다.

 

MVP 패턴

 

모델(Model) = 생산국: MVP에서도 모델은 생산국과 같은 역할을 합니다. 데이터와 비즈니스 로직을 "생산"하는 부분입니다.

뷰(View) = 소비자: 뷰는 여전히 소비자에 비유됩니다. 그러나 MVP에서는 뷰가 프레젠터를 통해서만 데이터를 받게 됩니다.

프레젠터(Presenter) = 독점 무역 대리인: MVP의 프레젠터는 컨트롤러와 비슷한 역할을 하지만, 뷰와 모델 사이의 상호작용을 더욱 직접적으로 관리합니다. 이는 독점 무역 대리인에 비유할 수 있습니다. 독점 무역 대리인은 특정 상품의 수입과 판매를 독점적으로 관리하며, 생산국(모델)으로부터 상품을 받아 직접 소비자(뷰)에게 전달합니다. 여기서 중요한 점은, 뷰가 모델에 직접 접근하지 않고 프레젠터(독점 무역 대리인)를 통해 모든 정보를 받는다는 것입니다.

 

MVVM 패턴

 

모델(Model) = 생산국: MVVM에서 모델은 여전히 생산국에 비유됩니다. 데이터와 비즈니스 로직을 "생산"하는 역할을 합니다. 이는 MVC와 MVP 패턴과 동일합니다.

뷰(View) = 소비자: 뷰는 사용자에게 UI를 통해 정보를 표시하는 역할을 하므로, 소비자에 비유할 수 있습니다. 소비자는 제품을 선택하고 사용하는 데에 있어 자율성을 가집니다.

뷰모델(ViewModel) = 수출입 대행사: MVVM의 핵심인 뷰모델은 수출입 대행사에 비유할 수 있습니다. 수출입 대행사는 생산국(모델)으로부터 상품을 받아 소비자(뷰)의 요구에 맞게 가공하고, 소비자가 원하는 상품을 쉽게 선택하고 구매할 수 있도록 중개하는 역할을 합니다. 뷰모델은 모델로부터 데이터를 받아, 뷰가 사용할 수 있는 형태로 가공하고, 뷰와의 데이터 바인딩을 통해 자동으로 UI를 업데이트합니다.

 

 

마지막으로 이 비유와, 각각의 단점이 어떤 케이스로 나타게 될지 작성해보겠습니다.   

 

  • MVC에서는 컨트롤러(Controller = 무역상)가 사용자의 입력을 처리하고 모델과 뷰 사이의 상호작용을 관리합니다. 여기서 뷰는 모델로부터 직접 데이터를 받을 수 있습니다. 이는 무역상이 생산국과 소비자 사이에서 상품의 흐름을 조정하지만, 소비자가 직접 생산국으로부터 상품을 구매할 수도 있는 상황에 비유할 수 있습니다.
  • 단점인 뷰와 모델 사이의 동기화 문제는 무역상이 소비자가 직접 상품을 구매하고 무역상을 통해 구매하는 두 거래의 동기화의 어려움에 비유해볼 수 있을 것 같습니다. 

 

  • MVP에서는 프레젠터(Presenter = 독점 무역 대리인)가 모델과 뷰 사이의 상호작용을 전적으로 담당합니다. 뷰는 모델에 직접 접근하지 않고, 모든 사용자 입력과 데이터 업데이트를 프레젠터를 통해 처리합니다. 이는 독점 무역 대리인이 생산국과 소비자 사이의 모든 상품 흐름을 관리하는 상황에 비유할 수 있습니다.
  • 프레젠터의 복잡성이 증가하는 단점은 거래의 규모와 복잡성이 증가함에 따라 대리인의 업무 부담이 크게 증가하는, 각 거래를 맞춤화하고 관리하는 과정에서 발생하는 복잡성에 비유해 볼 수 있을 것 같습니다. 

 

  • MVVM에서는 뷰모델(ViewModel = 수출입 대행사)이 뷰와 모델 사이의 중개자 역할을 하며, 데이터 바인딩을 통해 뷰와 모델 사이의 동기화를 자동으로 관리합니다. 뷰는 뷰모델을 통해서만 데이터를 받고, 사용자의 선택이나 액션은 뷰모델을 통해 모델에 반영됩니다. 이는 수출입 대행사가 생산국으로부터 상품을 받아, 소비자의 요구에 맞게 가공하고 소비자에게 제공하는 과정에 비유할 수 있습니다. 소비자는 대행사를 통해 원하는 상품을 보다 쉽게 선택하고 구매할 수 있습니다.
  • MVVM은 수출입 대행사가 생산국와 소비자에 관해 상품 정보의 자동 업데이트 시스템을 구축한 경우라 생각할 수 있습니다. 이 자동화 과정에서 발생하는 데이터의 동기화 및 전달 과정이 복잡해지고, 만약 정보 전달에 오류가 발생한다면 오류의 원인을 찾기 위한 디버깅이 매우 어려워진다고 할 수 있습니다. 
 

 

저작자표시

티스토리툴바