MVC, MVP, MVVM 패턴 정리

MVC(Model - View - Controller)

---

MVC패턴의 목적은 비즈니스 로직과 뷰를 분리하는 것입니다.

 

Model : 애플리케이션의 비즈니스 로직과 데이터를 담당합니다. 데이터를 가져오고 변경하는 메서드를 갖고 있으며, 데이터 변경 시에는 이를 관리하는 컴포넌트에 알립니다.

 

View : 사용자 인터페이스를 담당합니다. 모델의 데이터를 보여주고, 사용자의 입력을 받아 Model에 전달합니다.

 

Controller : 모델과 뷰를 연결하고, 애플리케이션의 흐름을 제어합니다. 뷰에서 입력을 받아 모델에 전달하거나, 모델에서 변경된 데이터를 가져와 뷰에 반영합니다.

 

비즈니스 로직 : 소프트웨어 시스템이 수행해야 하는 비즈니스 요구사항을 정의하는 부분을 말합니다.소프트웨어의 핵심 기능을 결정하며, 시스템이 수행해야 할 특정 작업을 기술합니다.

 

 

1. 모든 입력은 Controller로 전달됩니다.

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

3. 업데이트 결과에 따라 View를 선택합니다.
(Controller와 View는 1 : N의 관계로, Controller는 여러 개의 View를 관리합니다. 또한, Controller는 View를 선택만 할 뿐 직접 업데이트하지는 않습니다.)

4. View를 업데이트하기위해서는 아래와 같은 방법들이 있습니다.

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

 

• MVC패턴의 장점
  • 비교적 간단한 패턴으로 구조파악과 확장이 쉽습니다.
• MVC패턴의 단점
  • Model과 View 사이의 의존성이 크며, 앱이 클수록 복잡해지고 유지보수가 어렵습니다.

• MVC패턴의 문제점
  • View를 업데이트하기 위해서는 M - V의 의존성이 존재합니다.
  • 안드로이드는 Activity(or Fragment)가 Controller와 View 모두 처리하기 때문에, 한 클래스에서 M-V-C를 모두 처리하게 되는 문제점이 발생합니다.

 

MVP(Model - View - Presenter)

---

MVC패턴에서 M-V의 의존성을 없애기 위해 개선된 디자인 패턴입니다.

 

Model : 애플리케이션의 비즈니스 로직과 데이터를 담당합니다.

 

View : 사용자 인터페이스를 담당합니다. MVC의 패턴의 View와는 달리 Model에 직접 접근하지 않으며, Presenter를 통해 Model과 상호작용합니다.

 

Presenter : View와 Model사이의 중간자 역할을 합니다. View로부터 입력을 받아 Model에 전달하거나, Model로부터 Data를 받아 VIew에 전달합니다.

 

1. 사용자는 View를 통해 애플리케이션에 대한 요청을 보냅니다.

2. View는 사용자의 요청을 Presenter에게 전달합니다.

3. Presenter는 요청을 처리하기 위해 Model에 액세스 합니다.

4. Model은 데이터를 Presenter에게 반환합니다.

5. Presenter은 받은 데이터를 가공하여 VIew에 반환합니다.

6. View는 반환된 데이터를 표시합니다.

 

• MVP패턴의 장점
  • View와 Model이 직접 참조하지 않아, M-V 간의 의존성이 없습니다.
• MVP패턴의 단점
  • View와 Presenter는 1 : 1관계여서,  Application을 구현하는 과정에서 Presenter 코드의 중복이 많아진다.
  • View가 많아질수록 필요한 Presenter개수가 많아진다.
• MVP패턴의 문제점
  • Presenter가 M-V사이를 관리해주기 때문에, M-V의 의존성은 없는 대신, V-P의 의존성이 크다.

 

MVVM (Model - View - View Model)

---

MVC패턴에서 파생되어 M-V간의 의존성뿐 아니라, V-C의 의존성도 해결한 디자인 패턴

 

 

 

Model : 애플리케이션에서 비즈니스 로직과 데이터를 담당합니다. View와 View Model은 Model에게 직접 접근할 수 없으며, Model은 View와 View Model의 존재를 알 수 없습니다. 

 

View : 사용자 인터페이스를 담당합니다. View Model에서 받은 Data를 이용하여 UI를 구성합니다. 이벤트가 발생하면 ViewModel에 전달합니다. View는 View Model에 대한 참조를 갖고 있지만, View Model은 View에 대한 참조를 갖고 있지 않습니다. 

 

View Model : Model과 View의 사이의 중간자 역할을 합니다. View에 필요한 Data를 Model로부터 가져와 적절히 가공하여 View에게 전달합니다. View에서 발생하는 이벤트를 처리하고, Model로부터 Data가 변경될 때 마다 View에 이를 알려 View의 상태를 업데이트합니다. View와의 상호작용과 생명주기를 관리합니다. 

 

1. 사용자의 Action들은 View를 통해 들어옵니다.

2. View에 Action이 들어오면 View Model에 Action을 전달합니다.
    (View Model과 View는 1 : N 관계입니다.)

3. View Model은 Model에게 데이터를 요청합니다.
(Command 패턴이나 Data Binding을 이용하여 V-VM간의 의존성을 없앨 수 있습니다.) 

4. Model은 View Model에게 요청받은 데이터를 응답합니다.

5. ViewModel은 응답 받은 데이터를 가공하여 저장합니다.

6. View는 Data Binding을 이용해 UI를 갱신시킵니다.

 

Presentation Logic : 실제 눈에 보이는 GUI화면을 구성하는 코드를 말합니다.

Data Binding : UI와 Data사이의 동기화를 담당하여 View Model에서 Model이 변경될 때 이를 감지하고 UI를 자동으로 업데이트 합니다.

 

 

Q. Data Binding에서 어떻게 자동으로 이벤트를 감지하고 변경할까요?

---

Data Binding을 하기위해 일반적으로 Observer 패턴을 사용합니다.

Observer패턴이란 관찰 대상 객체는 자신의 상태가 변경될 때마다 자신을 관찰하고 있는 모든 객체에게 알리는 역할을 하며, Observer 객체는 등록된 관찰 대상 객체의 상태 변화를 감지하고 이에 대한 처리를 수행합니다. 

 

 - View가 View Model의 데이터를 관찰할 수 있는 방법들

1. Observable 객체 : Data가 변경될 때 마다 이를 감지해  UI를 업데이트
2. Live Data : Lifecycle-aware의 한 데이터 홀더로, 데이터가 변경될 떄마다 Observer에게 알려 UI를 업데이트
3. RxJava : Observerable 및 Observer를 사용하여 데이터 스트림을 처리하고 UI를 업데이트
4. Kotlin Flow : 코루틴 기반의 비동기적인 데이터 스트림 처리를 지원하며, UI 업데이트에 사용

 

• MVVM패턴의 장점 
  • M-V의 의존성이 없습니다.
  • VM-V의 의존성이 없습니다.
  • 중복되는 코드를 모듈화할 수 있습니다.
• MVVM패턴의 단점
  • ViewModel의 설계가 어렵다. 

 

 

- 참고

한 번의 글로 이해하는 소프트웨어 아키텍처 패턴 ( MVC, MVP, MVVM )

 

https://brunch.co.kr/@oemilk/113

MVC, MVP, MVVM, MVI

 

https://greedy0110.tistory.com/38

[아키텍쳐] MVVM 정리하기