MVC, MVP, MVVM 디자인 패턴 간단 정리

웹, 앱을 개발하다보면 자연스럽게 만나게 되는 개념이 아키텍처이고 MVC 패턴이라는 단어를 쉽게 만나볼 수 있습니다. 이런 아키텍처 패턴이 중요한 이유는 수없이 있겠지만 제가 체감한 경험은 다음과 같습니다.

1. 내가 쓴 코드를 다시 보거나 다른 사람이 내 코드를 볼 때 어떤 코드가 어디에 있을지 예상하기 쉽다.
2. 코드의 기능이나 로직이 잘 분류되어 있어 테스트를 할 때 간편하다.
3. 코드의 기능이나 로직이 잘 분류되어 있어 하나의 파일에 과도한 코드가 몰리는 것을 방지할 수 있다.

MVP, MVVM 패턴은 MVC 패턴의 파생 패턴이므로 MVC > MVP > MVVM 순으로 정리를 해보겠습니다.

 

0. Model과 View

본격적으로 아키텍처 패턴을 알아보기 전에 Model과 View를 제대로 알아보고 가야합니다.

 

Model은 데이터를 생성하거나 업데이트하는 역할을 맡고

View는 눈에 보이는 UI 화면을 구성합니다.

 

웹 개발이든 앱 개발이든 데이터와 UI를 연결하는 코드는 필수적이기 때문에 M과 V 사이에는 의존성이 생기게 됩니다.

 

개발 코드가 커져가면 자연스럽게 복잡성이 커지고 의존성도 더 강해집니다. 결국 MVC든 MVP든 C(Controller)와 P(Presenter)모두 M-V 사이의 관계를 잘 정돈하여 복잡성이나 의존성을 낮춰보고자 나온 아키텍처 패턴들입니다.

 

이제 진짜 제대로 앱 아키텍처 패턴(MVC, MVP, MVVM)을 알아보도록 합시다. 

1. MVC 패턴

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

 

동작

1. 모든 Input은 Controller로 전달됩니다.
2. Controller는 Input을 확인하고 Model을 업데이트합니다.
3. 업데이트 결과에 따라 View를 선택합니다.
   (하나의 Controller는 View를 선택할 수 있기 때문에 1:n 관계로, 여러 개의 View를 관리할 수 있습니다.)
4. Controller는 Model을 나타내줄 View를 선택만 할 뿐, 직접 업데이트하지는 않습니다.
   (View는 Controller를 알지 못합니다.)
5. View는 Model을 이용하여 화면을 나타냅니다. View를 업데이트하는 방법들은 아래와 같습니다.
   1. View가 Model을 직접 이용하여 업데이트
   2. Model에서 View에게 Notify하여 업데이트
   3. View가 Polling하여 Model의 변화를 감지하여 업데이트

특징

• 위 업데이트 방법을 보다시피 View를 업데이트 할 때 M-V 사이에 의존성이 존재하게 됩니다.

장점

• 단순하고 보편적이어서 구성하기 쉽습니다.

단점

• M-V 사이에 의존성이 높아 프로그램이 커질수록 복잡해져 유지 보수에 어려움을 겪습니다.
• 의존성이 높아 테스트하기에 불리합니다.
• 안드로이드의 경우 Activity나 Fragment에 Controller와 View 모두 처리하기 때문에, 한 클래스에 M-V-C 모두 처리하게 되는 문제점이 발생합니다.

 

2. MVP 패턴

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

 

동작

1. 모든 입력(Input)들은 View로 전달된다.
2. Presenter는 입력에 해당하는 Model을 업데이트한다.
3. Model 업데이트 결과를 기반으로 View를 업데이트 한다.
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 관계이기 때문에 서로 간의 의존성이 커집니다.
• 구현에 있어서 필요한 클래스의 수가 많아집니다.

 

3. MVVM 패턴

 

MVC에서 파생된, Model과 View간의 의존성 뿐만 아니라 Controller와 View간의 의존성도 고려하여서 각 구성 요소가 독립적으로 작성되고 테스트될 수 있도록 설계된 아키텍처 패턴입니다.

 

동작

1. 모든 입력(Input)들은 View로 전달된다.
2. ViewModel은 입력에 해당하는 Presentation Logic을 처리하여 View에 데이터를 전달한다.
   (Presentation Logic : 실제 눈에 보이는 GUI 화면을 구성하는 코드를 말하며 여기서는 실제로 화면에 보여지는 데이터를 처리하는 로직을 말한다.)
3. ViewModel은 View를 참조하지 않기 때문에 독립적이다.
   (ViewModel과 View는 1:n 관계다.)
4. 따라서 View는 이용할 ViewModel을 선택해 바인딩하여 업데이트를 받게 된다.
   (Command 패턴이나 Data Binding을 이용하여 V-VM간 의존성을 없앨 수 있다.)
5. Model이 변경되면 해당하는 ViewModel을 이용하는 View가 자동으로 업데이트된다.
6. ViewModel은 View를 나타내 주기 위한 Model을 처리하는 로직인 Presentation Logic을 처리한다.

 

 

특징

• MVP와 마찬가지로 M-V 사이의 의존성이 없고, MVP처럼 V-VM이 1:1 관계가 아니라 독립적이기 때문에 이 둘 사이의 의존성도 없다.

장점

• Model과 View 사이의 의존성이 없음
• ViewModel과 View 사이의 의존성이 없음
• 중복되는 코드를 모듈화할 수 있음
• 의존성이 낮아져 테스트가 용이해짐

단점

• ViewModel 설계가 쉽지 않다.

 

참고 문헌

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

MVC, MVP, MVVM, MVI