(Android) - MVC, MVP, MVI 패턴의 이해 및 장단점

 

오늘은 안드로이드 앱 개발 시 적용하는 아키텍처 패턴들을 파악해 보자.

 

[ 안드로이드 앱 개발 아키텍처 패턴의 종류 ]

- MVC (Model View Controller)

- MVP (Model View Presenter)

- MVVM (Model View ViewModel)

- MVI (Model View Intent)

- 등등

 

해당 패턴 이름을 보면 M(Model), V(View)를 공통적으로 가지고 있음을 확인할 수 있다.

- Model (데이터 or 데이터를 생성하거나 업데이트 / UI 상태임)

- View (UI or 화면을 표시 / xml 형식임으로 입력에 대한 동작에 대해서 모름)

 

프로그램의 Presentation Logic & Business Logic 들을 구현하기 위해선 데이터, UI 는 필수적이기 때문에 M-V 사이에선 의존성이 생길 수밖에 없다.

 

* Presentation Logic

: 실제 눈에 보이는 GUI (Graphic User Interface) 화면을 구성하는 코드를 뜻함

 

* Business Logic

: 데이터를 보여주기 위해 DB를 검색하는 코드 + GUI 화면에서 새롭게 발생한 데이터를 DB에 저장하는 코드 등 눈에 보이지 않는 데이터 처리, 기능 처리 등 (앱에 가치를 부여하는 요소로, 앱의 데이터 생성, 저장, 변경 방식을 결정하는 규칙으로 구성) 을 수행하는 코드를 뜻함

 

이러한 Logic 들이 커지고 복잡해짐에 따라 의존성은 강해지고 앱을 유지 보수하기 점점 더 어려워진다.

=> 이러한 문제를 해결하기 위해 여러 패턴들이 나왔지만 결국 M-V 사이의 관계를 어떻게 처리하는지에 따라 패턴들을 구분 지을 수 있다.

 

---

 

MVC (Model - View - Controller)

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

 

1. 모든 입력(Input)들은 Controller로 전달됨

 

2. Controller는 입력에 해당하는 Model을 업데이트함

 

3. 업데이트 결과에 따라 View를 선택함 (하나의 Controller는 View를 선택할 수 있기 때문에 1 : N 관계로 여러 개의 View를 관리할 수 있음)

 

4. Controller는 View를 선택만 할 뿐, 직접 업데이트하지 않음 (View는 Controller를 알지 못함)

 

5. View를 업데이트하기 위해 아래와 같은 방법을 사용

• View가 Model을 직접 이용하여 업데이트
• Model 에서 View 를 Notify 하여 업데이트
• View가 Polling 하여 Model 의 변화를 감지 후 업데이트

 

=> View를 업데이트하기 위해 결국 M <-> V 사이에 의존성이 존재하게 되며 안드로이드는 Activity(or Fragment)가 Controller와 View 모두 처리하기 때문에 한 클래스에서 M - V - C 모두를 처리하게 되는 문제점 발생

 

 

장점

- 가장 단순한 패턴이다

 

단점

- Model <-> View 사이의 의존성이 발생한다.

- 앱이 커지고 복잡해질수록 유지보수가 어려워진다.

 

---

 

MVP (Model - View - Presenter)

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

 

1. 모든 입력(Input)들은 View로 전달됨

 

2. Presenter는 입력에 해당하는 Model을 업데이트함 (P -> M)

 

3. Model 업데이트 결과를 기반으로 View를 업데이트함 (M -> V)

 

4. Presenter는 해당 View를 참조하고 있음. (View - Presenter 는 1 : 1 관계)

 

5. Presenter는 View와 Model 인스턴스를 가지고 Model과 View 사이의 매개체 역할을 함.

 

=> Presenter가 M-V 사이에서 매개체 역할을 하며 관리하기 때문에 MVC 패턴과는 달리 M-V 사이의 의존성이 없다. 하지만 앱이 커지거나 복잡해질수록 V-P 간 의존성이 강해지는 문제점이 발생함.

 

 

장점

- Model <-> View 사이의 의존성이 없다.

 

단점

- View와 Presenter가 1:1 관계이기 때문에 서로 간 의존성이 커짐

- 필요한 클래스 개수가 많음

 

---

 

MVI (Model - View - Intent)

JS 생태계에서 탄생했으며 MVC에서 파생된 능동적인 Controller 대신 Intent라고 불리는 Reactive 요소를 이용한 아키텍처 패턴

 

 

MVC에서 Controller가 직접 Model을 업데이트하고 View를 선택하는 능동적인 구조가 아닌 MVI는 Intent가 User를 관찰, Model이 Intent를 관찰, View가 model를 관찰, User가 View를 관찰하는 Reactive 요소로 이루어져 있다는 특징이 있음.

=> 안드로이드에서 RxJava와 같은 라이브러리가 필수적인 이유

 

 

1. Intent가 User로부터 입력(Input)을 가져옴 (Android의 Intent와 다른 개념임)

 

2. Intent는 Model에서 처리해야 하는 동작(Intended Action)을 제공함

 

3. Model은 Intent로부터 동작을 가져옴 (MVI의 Model은 단순 데이터 뿐만 아닌 Application 상태 (State)의 Business Logic을 관리함)

 

4. Model은 View에 표시할 새로운 모델을 생성함 (Immutability한 모델을 생성 = 객체가 최초 생성된 시점 이후 상태 값이 변하지 않음)

 

5. View는 Model로부터 새로운 Model을 가져와 표시함

 

 

장점

- 단방향, 불변성 데이터를 사용하기 때문에 예측 가능한 상태임

- 서로 간 의존성이 존재하지 않음

 

단점

- RxJava와 같은 Observable한 외부 라이브러리를 이용해야 함

 

---

 

https://brunch.co.kr/@mystoryg/170

안드로이드 MVC

https://brunch.co.kr/@mystoryg/171

안드로이드 MVP