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

 

 

웹, 앱 개발 시에는 요구되는 여러 아키텍처 패턴들이 있다.

 

• MVC (Model-View-Controller)
• MVP (Model-VIew-Presenter)
• MVVM (Model-View-ViewModel)
• MVI (Model-View-Intent)
• 기타

 

 

이름에는 각각 M(Model)과 V(View)를 공통적으로 가지고 있는데, 이들은 다음과 같은 기능을 수행한다.

 

 

• Model: 웹/앱에서 사용되는 데이터와 그 데이터를 처리하는 부분 (생성 or 업데이트)
• View: 사용자에게 보여지는 UI 부분

 

 

 

프로그램의 Presentation logic＊, Business logic＊ 을 구현할 때에는 데이터와 UI가 필수적이기 때문에

당연히 M-V 사이의 의존성이 생길 수밖에 없다.

 

Presentation logic -  실제 눈에 보이는 GUI 화면을 구성하는 코드 로직 Business logic-  사용자의 눈에 보이진 않지만, 사용자가 바라는 결과물을 올바르게 도출할 수 있게 짜여진 코드 로직 ex) 데이터를 보여주기 위해 DB를 검색하는 코드ex) GUI 화면에서 새롭게 발생된 데이터를 DB에 저장하는 코드

 

 

이러한 로직들이 크고 복잡해지면 프로그램의 의존성은 높아질 수 있으며,

유지보수 하는데에 어려움을 느낄 수 있다.

 

 

이러한 문제들을 해결하기 위해 만들어진 것이 바로 위에서 설명한 아키텍처 패턴들이다.
해당 패턴들은 M-V 사이의 관계를 처리하는 방법에 따라 구분된다.

 

 

 

MVC

"Model-View-Controller"

 

프로그램을 역할에 따라 Model, View, Controller 로 나누어 설계한 아키텍처 패턴

 

1) 구조

MVC 구조

• Model: 웹/앱에서 사용되는 데이터와 그 데이터를 처리하는 부분 (생성 or 업데이트)
• View: 사용자에게 보여지는 UI 부분
• Controller: 사용자의 입력(Action)을 받고 처리하는 부분 

 

2) 동작

1. 사용자의 모든 Action들은 Controller에 들어오게 된다.
2. Controller는 사용자의 Action을 확인하고, Model을 업데이트한다.
3. Controller는 Model을 나타낼 View를 선택한다.
4. View는 Model을 이용하여 화면을 나타낸다.

 

3) 특징

1. Controller는 여러 개의 View를 선택할 수 있는 1:N 구조이다.
2. Controller는 View를 직접 선택할 뿐 업데이트 하지 않는다

※ MVC에서 View가 업데이트 되는 방법  View가 Model을 직접 업데이트 하는 방법 Model에서 View에게 Notify(통지)하여 알리는 방법 VIew가 Polling[각주:1]으로 주기적으로 Model의 변경을 감지하여 업데이트 하는 방법

 

 

3) 장점

MVC 패턴의 장점은 보편적으로 사용되고 있는 아키텍처 패턴이라는 점에 걸맞게 가장 단순하다.

 

4) 단점

1. MVC 패턴의 단점은 Model-View 사이의 의존성이 높다는 점이다. 
2. 둘 사이의 의존성이 높아지면 프로그램의 유지보수가 어려워질 수 있다.

 

 

 

MVP

"Model-View-Presenter"

 

MVC에서 파생된 Model - View 간 의존성이 없는 아키텍처 패턴

 

 

 

1) 구조

MVP 구조

• Model: 웹/앱에서 사용되는 데이터와 그 데이터를 처리하는 부분 (생성 or 업데이트)
• View: 사용자에게 보여지는 UI 부분
• Presenter: View에서 요청한 정보로 Model을 가공하여 View에 전달해주는 부분 (Model-View 사이의 매개체 역할)

 

2. 동작 

1. 사용자의 Action은 View를 통해 들어온다.
2. View는 데이터를 Presenter에 요청한다.
3. Presenter은 Model에게 데이터를 요청한다.
4. Model은 Presenter에서 요청받은 데이터를 응답한다.
5. Presenter은 VIew에게 데이터를 응답한다.
6. View는 Presenter로부터 응답받은 데이터를 이용하여 화면을 나타낸다.

 

3. 특징

1. Presenter과 View는 1:1 구조이다.
2. Presenter은 View, Model의 인스턴스를 가지고 있어서 둘을 연결하는 매개체 역할을 수행한다.

 

4. 장점

MVP 패턴의 장점은 Model-View 사이의 의존성이 없다는 것이다.

따라서 MVC의 단점을 보완한 아키텍처 패턴임을 알 수 있다.

 

5. 단점

1. View와 Presenter가 1:1 구조이기 때문에 서로 간의 의존성이 커진다.
2. 구현에 필요한 클래스의 수가 많아진다.

 

 

 

MVVM

"Model-View-View Model"

 

MVC 패턴에서 Controller을 빼고 ViewModel을 추가한 아키텍처 패턴

 

 

1) 구조

MVVM 구조

• Model: 웹/앱에서 사용되는 데이터와 그 데이터를 처리하는 부분 (생성 or 업데이트)
• View: 사용자에게 보여지는 UI 부분
• ViewModel: View를 표현하기 위해 만든 View를 위한 Model

 

2) 동작

1. 사용자의 Action은 View를 통해 들어온다.
2. View에 Action이 들어오면, Command 패턴^[각주:2]으로 View Model에 Action을 전달한다.
3. View Model은 Model에게 데이터를 요청한다.
4. Model은 View Model에게 요청받은 데이터를 응답한다.
5. View Model은 응답 받은 데이터를 가공하여 저장한다.
6. View는 View Model과 Data Binding^[각주:3]하여 화면을 나타낸다.

 

3) 특징

1. Command 패턴, Data Binding 두 가지 패턴을 사용한다.
2. Command 패턴, Data Binding 을 이용하여 View-View Model 사이의 의존성을 없앴다.
3. View Model과 View는 1:N 구조이다.

 

4) 장점

1. View-View Model 사이의 의존성이 없다.
2. Command 패턴, Data Binding 을 이용하여 View-View Model 사이의 의존성이 없다.
3. 의존성이 낮아 테스트, 유지보수가 용이하다.
4. 중복되는 코드를 모듈화할 수 있다.

 

5) 단점

View Model을 설계하는 것이 복잡하다.

 

 

 

참고문헌

• https://magi82.github.io/android-mvc-mvp-mvvm/

 

1. 하나의 장치가 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식 [본문으로]
2. 요청을 객체의 형태로 캡슐화하여 사용자가 보낸 요청을 나중에 이용할 수 있도록 매서드 이름, 매개변수 등 요청에 필요한 정보를 저장 또는 로깅, 취소할 수 있게 하는 패턴 [본문으로]
3. 제공자와 소비자로부터 데이터 원본을 결합시켜 이것들을 동기화하는 기법 [본문으로]