[안드로이드 아키텍처 패턴]MVC,MVP,MVVM

대표적인 안드로이드 아키텍처 패턴 MVC,MVP,MVVM 에 대해서 정리해보고자 한다. 아키텍처 패턴은 코드 사이의 종속성을 낮추기 위해 사용되고, 종속성을 낮추면 자연스레 코드간 의존성도 낮아지고~ 유닛 테스트도 용이해지기 때문에 아키텍처 적용을 권장하고 있다.

---

1️⃣ MVC 패턴

MVC 패턴은 안드로이드 아키텍처 패턴중 가장 널리 사용되는 패턴이다.
Model - View - Controller로 구성되어 있고 각 부분의 설명은 아래와 같다.

• Model
  애플리케이션에서 사용되는 데이터와 데이터를 처리하는 역할

• View
  사용자에게 보여지는 화면

• Controller
  사용자에게 입력을 받고 Model을 통해 View를 적용시키는 역할
  입력처리와 흐름제어를 담당한다.

  
  

⚒ MVC 기본 동작과정

1. User Input이 Controller를 통해 들어온다. (C)
2. Input에 의한 업데이트가 있는지 체크한다. (C)
3. Cotroller에서 전달받은 업데이트를 확인하고, 업데이트 해준다. (M)
4. Model에서 업데이트 된 이벤트를 수신한다. (V)
5. 데이터를 Model에게 요청한다. (V)
6. 요청받은 데이터를 갱신하여 View에게 전달한다. (M)
7. 전달받은 데이터를 가지고 UI를 갱신한다. (V)

위와 같은 과정은 일반적인 MVC의 동작과정이다. 하지만 안드로이드의 경우 View와 관련된 Activity와 Fragment에서 View,Cotroller의 역할을 모두 수행하고 있다.

⚒ Android에서 MVC 동작과정

1. User Input이 들어온다. (V/C)
2. Input에 의한 업데이트가 있는지 체크한다.(V/C)
3. View/Cotroller에서 전달받은 업데이트를 확인하고, 업데이트 해준다. (M)
4. Model에서 업데이트 된 이벤트를 수신한다. (V/C)
5. 데이터를 Model에게 요청한다. (V/C)
6. 요청받은 데이터를 갱신하여 View/Cotroller에게 전달한다. (M)
7. 전달받은 데이터를 가지고 UI를 갱신한다. (V/C)

👍🏻 장점

• Model과 View의 분리
• 구현하기 가장 쉽고 단순하다.
• 개발기간이 짧아진다.
• 유닛테스트에서 View는 테스트할 부분이 없고, 쉽게 Model만 테스를 할 수 있다.

👎🏻 단점

• Model과 View 사이에 의존성이 발생한다.
  View의 갱신을 위해선 Model이 계속 간섭하기 때문에 앱이 커지게 된다면 유지보수가 힘들어진다.
• 시간이 지날수록 Cotroller에 많은 코드가 쌓인다. ( Cotroller가 다수의 View를 선택할 수 있기 때문, V-C 관계는 One-To-Many 또는 Many-To-Many)

MVC의 가장 큰 단점은 Model과 View사이의 의존성이다. 좀 더 자세히는 **Model이 View에 끼치는 연관**성이다. View는 Model에게 연관이나 영향을 끼치고 있지는 않다. 앱의 규모가 커지게 된다면 이부분이 매우 치명적이기 때문에 이를 보완한 `MVP 패턴` 이 등장하게 된다.

---

2️⃣ MVP 패턴

view와 model을 완전하게 분리하기 위해 등장한 아키텍처 패턴이다.
Model - View - Presenter로 구성되어 있고 View와 Model을 MVC 패턴에서의 역할과 같다.

• Presenter
  뷰와 모델 사이에서 자료 전달 역할을 한다.
  

⚒ MVP 기본 동작과정

1. User Input이 View를 통해서 들어온다.
2. View가 Presenter에게 이벤트를 전달한다.
3. 전달 받은 이벤트에 따라 데이터를 요청한다. (P)
4. 데이터를 업데이트 한다. (M)
5. 업데이트한 데이터를 Presenter에게 전달한다. (M)
6. 업데이트된 데이터를 가공하여 View에게 전달한다. (P)
7. 가공된 데이터를 UI에 갱신해준다. (V)

MVC와 다른점이 확 눈에 띄는데 바로 `Model과 View 사이의 의존성` 이 없어졌다는 점이다. 중간에서 Presenter를 통해 데이터를 주고받고 UI를 갱신시키고 있다.

V-P의 관계는 One-To-One관계 이므로 View마다 각각의 Presenter가 존재한다는 의미이다.
-> 이 점으로 인해 MVP의 패턴일 경우 코드의 수는 증가 할 수 있다.

👎🏻 장점

• Model과 View간의 결합도를 낮춰준다.
• 새로운 기능을 추가하거나 변경할 필요가 있을 땐 관련된 부분만 수정할 수 있다. -> 확장성이 좋다.
• 유닛테스트하기에 편리하다.

👎🏻 단점

• V-P 관계가 1:1이다.
• MVC 패턴에 비해 코드량이 많아진다.

---

3️⃣ MVVM 패턴

MVC와 MVP 패턴의 단점을 보완하며 등장한 아키텍처 패턴이다. 최대한 기능적인 작은 단위로 나누어서 큰 프로젝트 관리에도 용이하고, 테스트도 쉽다.
Model - View - ViewModel 로 구성되어 있으며 Model은 MVC 패턴에서의 역할과 같다.

• View
  사용자 눈에 보여지는 화면을 의미한다.
  View는 ViewModel을 관찰하고 있다가 상태 변화과 감지된다면 화면을 갱신하는 역할을 한다.

• ViwModel
  View와 Model 사이의 매개체 역할을 한다.
  V-VM은 1:N 를 가질 수 있고 여러개의 Activity가 하나의 ViewModel을 가질 수 있다.
  모든 View와 관련된 로직이 이곳에서 수행되며 , 데이터를 View에서 쉽게 보여질 수 있는 Model로 바꾸는 역할을 한다.

⚒ MVVM의 기본 동작과정

1. 사용자에게 보여지는 화면 View에서 Input을 받는다.
2. View에 Input이 들어오면, command 패턴으로 View Model에 Action을 전달한다.
3. View Model은 Model에게 데이터를 요청한다.
4. Model은 ViewModel에게 요청받은 데이터를 응답한다.
5. ViewModel은 응답받은 데이터를 가공하여 저장한다.
6. View는 ViewModel과 DataBinding하여 화면을 나타낸다.

command 패턴과 Data Binding 두가지 패턴을 사용하여 View와 ViewModel 사이의 의존성을 없앴다는 점이 특징이다. 더 자세한 MVVM패턴을 살펴보기 위해 추후에 두가지 패턴에 대해서도 알아보겠다!!

👍🏻 장점

• View-Model 사이의 의존성이 없다.
• View-ViewModel 사이의 의존성 또한 없다.
• 각각의 부분이 독립적이기 때문에 모듈화하여 개발할 수 있다.

👎🏻 단점

• Command 패턴, DataBinding과 같은 추가의 학습이 필요하다.
• 설계하기 어렵다. 매우!

---

참고

• [디자인패턴] MVC, MVP, MVVM 비교
• 안드로이드 아키텍처 패턴 - MVVM이 뭘까?