MVC, MVP and MVVM

MVC (Model View Controll) :

• Model
  • 데이터를 갖고 있고 애플리케이션에서 사용되는 데이터를 처리함.
  • View 또는 Control에 묶이지 않아서 재사용 가능함.
• View
  • 사용자에게 제공되는 UI
  • 사용자가 앱과 상호작용할 때 컨트롤러와 통신하는 책임을 맡습니다
• Control
  • 컨트롤러는 뷰로부터 사용자에게 입력을 받거나 이벤트가 발생하면 로직에 맞게 모델을 변경하게 됩니다.
  • 모델에서 데이터가 변화되는 것에 따라 컨트롤러는 뷰의 상태를 적절하게 업데이트 시킵니다
  • MVC 디자인 패턴에서는 Activity와 Fragment는 뷰의 역할을 하는 동시에 컨트롤러 역할도 하게 됩니다.

장점 : 

• MVC의 가장 큰 장점은 '모델에서 데이터를 가져와서 뷰에 구현을 하고 컨트롤러를 통해 이벤트가 발생하면 모델과 뷰를 갱신' 이라는 구조로 직관적이고 단순합니다.
• 구조가 단순 -> 작은 애플리케이션 개발 빠르게. (큰 어플리케이션일 경우 더 복잡해져서 느려질듯..)

단점 :

• 구조가 단순한 만큼 Activity, Fragment에 모든 코드가 편중
• 컨트롤러는 특정 뷰와 모델에 의존적이며, 뷰도 특정 모델에 의존적이라서 결합도가 높아 유닛테스트가 거의 불가능합니다.

MVP (Model View Presenter) :

MVP 패턴이 나온 이유: MVP의 핵심 설계는 MVC와는 다르게 UI(View)와 비즈니스 로직(Model)을 분리하고, 서로 간에 상호작용을 다른 객체(Presenter)에 그 역할을 줌으로써 서로의 영향(의존성)을 최소화하는 것에 있습니다.

 

• Model : MVC에서의 model 역할과 같음.
• View
  • View도 동일하게 사용자에게 제공되는 UI 부분
  • 하지만 MVC와는 다르게 Activity, Fragment는 View 역할만 할 뿐 컨트롤러 역할을 하지 않습니다.
  • Activity가 View Interface를 implements 하여 이를 통해 특정 View에 결합하는 것을 제거하고 View의 모의 구현으로 단위 테스트가 가능해집니다.
• presenter
  • Model과 View사이의 연결.
  • MVC에서의 View와 다르게 직접 연결되는 대신 인터페이스를 통해 상호작용 한다는 점이 다름.
  • 인터페이스를 통해 상호작용 하므로 MVC가 가진 테스트 문제와 함께 모듈화/유연성 문제 역시 해결할 수 있음. 
  • 뷰에게 표시할 내용(Data)만 전달하며 어떻게 보여줄지는 View가 담당.

MVP의 장점

• Model과 View의 결합도를 낮춤.
• 새로운 기능 추가 및 변경을 할때 마다 관련된 부분만 코드를 수정하면 되기 때문에 확장성이 개선됩니다.
• 또한, UI, Data 각각 파트를 나누어서 해야할 일(역할)이 명확해지고, 쉽고 빠른 코딩이 가능합니다.

MVP의 단점

•  어플리케이션이 복잡해질수록 View와 Presenter 사이의 의존성이 강해지는 문제가 있습니다. 
•  View가 많아질수록 Presenter도 많아진다. 
•  개발자는 오랜 시간 앱을 개발하는 어느 순간, 거대해지며 문제가 발생하기 쉽고, 분리하기 어려운 Presenter를 발견하게 됩니다. (물론, 초기에 설계/기획을 잘하면서 앱의 다양한 변화에 따라 대응한다면 위와 같은 문제는 발생하지 않지만, 그것마저도 쉽지 않다.)

MVVM(Model View ViewModel) :

MVVM 패턴은 Model, View, ViewModel을 분리해 뷰에 모델간의 의존성을 줄여주도록 한다. Model과 View의 의존성뿐만 아니라 Controller와 View의 의존성을 고려해 각 구성 요소를 독립적으로 작성.

• Model : MVC, MVP와 비슷하게 모델은 비즈니스 로직을 나타내고 클래스의 집합으로 특징된다. 이 부분은 데이터가 바뀌고 조작되는지에 대한 비즈니스 규칙을 디자인하는데 동작한다.
• View : 마찬가지로 MVC, MVP와 비슷하게 뷰는 UI 컴포넌트를 나타낸다. 뷰는 컨트롤러가 폼 형태로 되돌려준 결과를 보여준다. 모델은 또한 UI에 뷰로 변환될 수 있다.
• View Model :
  • View를 나타내주기 위한 Model + View의 로직 담당
  • View와 독립적
  • Model이 변경되면 해당 ViewModel을 사용하는 View가 자동으로 업데이트
  • ViewModel은 View를 따로 참조하지 않기 때문에 독립적이며 ViewModel과 View는 1:n의 관계입니다.

장점 : Model - View, View - Presenter 같은 의존성  X. 

단점 : ViewModel 설계가 어려울수 있음. View 에 대한 처리가 복잡해질수록 ViewModel 에 거대해지게 되고 상대적으로 Activity 는 아무런 역할도 하지 않는 형태의 클래스로 변모하게 됩니다.

 

MVP와 MVVM의 차이 : https://handnew04.github.io/posts/2020-11-24/

Presenter는 View를 직점 참조하고, ViewModel은 따로 View를 참조하지 않아서 독립적!!!