[Architecture] MVVM, MVI, MVP, MVC 비교

MVC

MVC

•  Model  + View + Controller
  • Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분 (비즈니스 로직 담당)
  • View : 사용자에서 보여지는 UI 부분
  • Controller : 사용자의 입력(Action)을 받고 처리하는 부분
• 동작
  • 사용자의 Action이 Controller에 들어옴 
  • Controller는 사용자의 Action을 확인하고 Model을 업데이트 함
  • Controller는 Modek을 나타내일 View를 선택
  • View는 Model을 이용해 화면 출력
• 특징
  • Controller는 여러개의 View를 선택할 수 있는 1:n 구조
  • Controller는 View를 선택할 뿐 직접 업데이트 하지 못함 (View는 Controller를 알지 못함)
• 장점
  • 비교적 단순한 패턴
• 단점
  • View와 Model 사이의 의존성이 높음 -> 앱이 커질수록 유지보수가 어려움 

 

 

 

 

MVP

MVP

• Model  + View + Presenter
  • Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분 (비즈니스 로직 담당)
  • View : 사용자에서 보여지는 UI 부분
  • Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달해 주는 부분

• 동작 
  • 사용자의 Action이 View를 통해 들어옴 
  • View는 데이터를 Presenter에 요청
  • Presenter는 Model에 데이터 요청
  • Presenter는 View에게 데이터를 응답
  • View는 Presenter가 응답한 데이터를 이용해 화면 출력
• 특징
  • Presenter와 View 1:1 구조 
• 장점
  • View와 Model사이의 의존성이 없음 (Presenter 사용)
• 단점
  • View와 Presenter 사이의 의존성이 높음 

 

 

 

MVVM

MVVM

• Model + View + ViewModel
  • Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분 (비즈니스 로직 담당)
  • View : 사용자에서 보여지는 UI 부분
  • ViewModel : View를 표현하기 위해 만든 Model로 View를 나타내며 필요한 데이터를 처리하는 부분  
• 동작
  • 사용자의 Action이 View를 통해 들어옴 
  • View에서 Action이 들어오면, Command 패턴으로 ViewModel에 Action전달
  • ViewModel은 Model에 데이터 요청
  • Model은 ViewModel에게 요청받은 데이터를 응답
  • ViewModel은 응답 받은 데이터를 가공하여 저장
  • ViewModel의 데이터를 Databinding 하여 View에 출력
• 특징
  • Command 패턴과 Databinding을 통하여 View와 ViewModel 사이의 의존성을 없앰
    • Command 패턴? : 커맨트 패턴(Command pattern)은 이벤트가 발생했을 때 실행될 기능이 다양하면서도 변경이 필요한 경우에 이벤트를 발생시키는 클래스를 변경하지 않고 재사용하고자 할 때 유용하다. 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴이다.
  • View와 ViewModel의 관계는 1:n
• 장점
  • View와 Model사이의 의존성이 없으며, Command 패턴과 Databinding을 사용하여 View와 ViewModel 사이의 의존성 또한 없앤 디자인 패턴
  • 각각 독립적이기 때문에 모듈화 하여 개발 가능
• 단점
  • View와 ViewModel 설계가 쉽지 않음 

 

 

 

 

MVI

• Model + View + Intent
  • Model : 다른 패턴에 있는 Model이하는 일인 데이터 저장을 하는 일에 추가적으로 데이터의 상태냄, MVI 특징인 데이터 단방향(Uni-drectional)을 지키기 위해 불변성을 지녀야 함
  • View : 사용자에서 보여지는 UI 부분
  • Intent : 앱이나 사용자의 이벤트를 나타냄 (사용자와의 상호작용을 통한 모든 UI 변화는 Intent의 함수 결과로 동작), 안드로이드의 Intent와는 다른 개념
• 동작
  • Intent로 View의 이벤트를 가져옴
  • Model은 Intent로부터 동작을 가져오며, View에 표시할 새로운 Model을 생성
  • View는 Model이 생성한 새로운 Model을 가져와 화면에 표시
  • 즉, 단방향으로 진행되며 데이터 흐름의 불변성을 가짐
• 장점
  • 데이터 단방향 흐름으로 유지보수가 편함 (디버그와 테스트에 용이)
  • View의 생명주기동안 일관성있는 상태를 가짐
• 단점
  • 너무 많은 boilerplate코드