MVC, MVP, MVVM 패턴

 

 

1. MVC ( Model  + View + Controller)

MVC 패턴을 사용하는 목적은 View와 Model사이에 Controller를 두어 View와 Model의 의존성을 없애기 위함.

 

1.1 구조

- Model : 데이터와 데이트를 처리하는 부분

- View : 사용자에게 보여지는 부분

- Controller : 사용자의 입력(Action)을 받고 처리하는 부분

 

1.2 동작

1) 사용자의 Action들은 Controller가 감지 한다. 

2) Controller는 사용자의 Action을 확인하고, Model을 업데이트 한다.

3) Controller는 Model을 표현해줄 View를 선택한다. 

4) View는 Model을 이용하여 화면을 나타낸다. 

 

1.3 특징

Controller는 여러개의 View를 선택할 수 있고, Controller는 View를 직접 업데이트 하지 않는다.

1) 장점

- 가장 널리 사용되고 있는 패턴

- 가장 단순함

- 보편적으로 많이 사용

2) 단점 

- View와 Model사이의 의존성이 높다.

- 어플리케이션이 커질수록 복잡해지고 유지보수가 어렵다. 

 

1.4 View 업데이트 방법

- View가 Model을 이용하여 직접 업데이트 하는 방법

- Model이 View에게 Notify해줘서 업데이트 하는 방법

- View가 Polling을 이용해 주기적으로 Model의 변경을 감지하여 업데이트 하는 방법

- Polling : 충돌 회피 또는 동기화 처리 등을 목적으로 다른 프로그램의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식

 

 

 

2. MVP (Model + View + Presenter)

 MVP는 MVC에서 View와 Model의 의존성을 완벽하게 분리한 패턴입니다. (MVC에서 Controller가 Presenter로 바뀜)

Presenter는 View의 인스턴스를 갖고 있으며 View에서 요청이 발생하면 이벤트에 따른 Model의 상태를 변경시킵니다. 

철저하게 View와 Model를 분리시키고, View와 Model사이에 다리 역할을 수행합니다. 

 

MVC 패턴에서는 사용자 입력이 컨트롤러로부터 왔습니다. 대부분의 프레임워크에서 url 요청을 받는 라우터는 컨트롤러로 연결됩니다. 

그러나 MVP 패턴에서는 사용자 입력이 View에서 발생합니다. View에서 요청이 발생하면 Presenter로 전달하고 Presenter에서는 그 이벤트에 따른 Model의 상태를 업데이트 시킵니다.

Model이 업데이트 되면 Presenter에서는 그 결과를 다시 View에 전달합니다. 

 

2.1 구조

- Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분

- View : 사용자에게 보여지는 UI부분

- Presenter : View에서 요청한 정보를 Model을 가공하여 View에 전달해 준다. (View와 Model의 다리같은 존재)

 

2.2 동작

1) 사용자의 Action들은 View를 통해 들어온다.

2) View는 데이터를 Presenter에 요청한다. 

3) Presenter는 Model에게 데이터를 요청한다. 

4) Model은 Presenter에서 요청받은 데이터를 응답한다. 

5) Presenter는 View에게 데이터를 응답한다. 

6) View는 Presenter가 응답한 데이터를 이용하여 화면을 나타낸다. 

 

2.3 특징

Presenter는 View, Model의 인스턴스를 가지고 있어 둘을 연결한다. (Presenter와 View는 1:1관계이다.)

1) 장점

- View와 Model의 의존성이 없다. (Presenter를 통해서만 데이터를 전달 받기 때문)

2) 단점 

- View와 Presenter사이의 의존성이 높음

- 어플리케이션이 복잡해 질수록 View와 Presenter사이의 의존성이 강해짐

 

 

 

3. MVVM (Model + View + View Model)

 MVP 패턴은 View와 Model간의 의존성을 분리시켰습니다. 그러나 View와 Presenter의 관계는 1:1이기 때문에 Presenter는 View와 의존성이 깊다고 할 수 있습니다. MVP패턴 역시 View와 Presenter간의 의존성이 깊기 때문에 이 문제를 해결하는 것이 MVVP모델이다. 

 MVVP 모델은 MVC 모델의 Controller, MVP 모델의 Presenter 대신 ViewModel로 바뀐 모델이다. (ViewModel은 View를 나타내기 위한 Model)

 MVVP 모델은 MVP 모델과 같이 View에서 입력이 들어온다. 입력이 들어오면 Command 패턴을 통해 ViewModel에 명령을 내리게 되고 ViewModel은 Model에게 필요한 데이터를 요청한다. 

 Model은 ViewModel에 필요한 데이터를 응답하고 Data Binding을 통해 ViewModel의 값이 변화하면 바로 View의 정보가 바뀌게 됩니다. 

 즉, Command와 Data binding을 통해 view의 의존성을 끊어버렸습니다. 이로써 view와 model의 분리가 이루어졌고, MVP패턴의 문제점을 해결했습니다. 

 

3.1 구조

- Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분

- View : 사용자에서 보여지는 UI 부분

- View Model : View를 표현하기 위해 만든 View를 위한 Model이다. View를 나타내 주기 위한 Model이자 View를 나타내기 위한 데이터 처리를 하는 부분.

 

3.2 동작

1) 사용자의 Action들은 View를 통해 들어온다.

2) View에 Action이 들어오면, Command 패턴으로 View Model에 Action을 전달

3) View Model은 Model에게 데이터를 요청한다. 

4) Model은 View Model에게 요청받는 데이터를 응답한다. 

5) View Model은 응답 받은 데이터를 가공하여 저장한다. 

6) View는 View Model과 Data Binding하여 화면을 나타낸다.

 

3.3 특징 

- Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현됨

- Command 패턴과 Data Binding을 이용하여 View와 View Model 사이의 의존성을 없앴다. (View Mode과 View는 1:n 관계)

1) 장점 

- View와 Model 사이의 의존성이 없다. 

- Command 패턴과 Data Binding을 사용하여 View와 View Model사이의 의존성 또한 없앤 디자인 패턴이다. 

- 각각의 부분은 독립적이기 때문에 모듈화 하여 개발 할 수 있다. 

2) 단점 

- View Model의 설계가 어렵다.