서론
MVC, MVP, MVVM은 모두 아키텍처 패턴의 종류이다.
모두 공통적으로 데이터를 정해진 구조로 나타내는 M(모델)과 사용자가 보는 화면과 사용자 인터페이스를 담당하는 V(뷰)를 포함하고 있다.
이러한 아키텍처 패턴이 필요한 이유는 어플리케이션이 복잡해질수록 뷰 마다 필요한 모델과 처리가 달라지고, 모델 역시 늘어나는 뷰에 따라 처리해야 할 로직이 많아지면서 코드가 복잡해지고 유지보수가 어려워진다는 문제가 있다.
때문에 M-V의 관계를 적절히 처리하여 유지보수성이 높은 코드를 작성하기 위해 MVC, MVP, MVVM 등의 아키텍처 패턴이 등장하게 되었다.
MVC
MVC는 모델-뷰-컨트롤러로 구성된 아키텍처 패턴이다.
-
모델(model) : 애플리케이션의 데이터인 데이터베이스, 상수, 변수 등을 뜻함, 컨트롤러에 의해 생성 또는 업데이트 된다.
-
뷰(view) : 사용자 인터페이스 요소를 나타냄. 모델을 기반으로 사용자가 볼 수 있는 화면
-
컨트롤러(Controller) : 모델과 뷰를 잇는 다리역힐. 사용자의 입력을 받아 이를 적절히 처리하는 메인 로직을 담당. 모델 업데이트 시 업데이트를 보여줄 뷰를 선택한다. (선택만 함)
구조
-
사용자의 입력은 controller에 전달
-
controller는 사용자 동작에 따라 입력을 적절히 처리하여 model을 업데이트
-
controller가 업데이트 결과를 보여줄 view를 선택 (직접 업데이트 X)
-
model이 업데이트 되면 view에서 이를 적절히 확인하여 화면 업데이트
- 1) view가 model를 주기적으로 바라보고 있다가(pooling), 업데이트가 발생하면 반영
- 2) model 업데이트시 model이 view에게 notify를 보내어 반영하게 함
- 3) view가 직접 model을 이용하여 업데이트
장점
- 구조가 단순하여 설계 및 구현이 쉽다.
단점
- model과 view가 서로 의존적이기 때문에 어플리케이션이 커질수록 모델과 뷰의 관계가 복잡해진다.
MVP
MVP는 모델-뷰-프레젠터로 구성된 아키텍처 패턴이다.
프레젠터(Presenter) : view와 model의 인스턴스를 가지고 둘 사이의 매개체 역할을 한다.
이를 통해 M-V간의 의존성을 없앤 아키텍처 패턴이다.
M-V가 1:1의 강한 연결을 갖는다는 특징이 있다.
구조
-
사용자의 입력은 view로 전달
-
view는 입력의 처리를 하고 필요한 데이터를 presenter에 요청
-
presenter는 model에서 필요한 데이터를 받아 view에 전달
-
view는 입력 처리 후 화면에 나타내고, presenter에 model 업데이트 요청
-
presenter는 처리된 데이터를 받아 model 업데이트
장점
- model과 view 사이의 의존성이 없다.
단점
- view와 presenter 사이에 강한 1:1 관계의 의존성이 생긴다.
MVVM
뷰 모델(View Model) : 뷰를 추상화한 계층으로 뷰와 1:N 관계를 갖는다. 뷰 모델은 뷰를 알지 못하고 알림만 전송할 수 있다. 뷰는 데이터바인딩, 커맨드를 통해서 뷰 모델을 지켜보고 있다.
구조
-
사용자의 입력은 view로 전달
-
view는 command 패턴을 통해 view model로 데이터 및 액션 전달
-
view model은 model에서 필요한 데이터를 요청하여 액션을 처리하고 model 업데이트 및 처리된 데이터를 변수 등에 저장
-
view는 data binding을 통해 view model의 변수와 연동되어있어 변경된 변수 내용을 반영해 화면에 나타냄
장점
- 1:1 관계를 갖지 않아도 되므로 확정이 더 용이하다.
- 의존성이 존재하지 않아 각각의 모듈을 독립적으로 개발 가능
단점
- 뷰모델의 설계가 어려움
