model, view, viewModel
•
발전 과정
MVC → MVP → MVVM
•
MVC 패턴
Controller가 너무나 많은 역할을 한다고 느꼈다.
레이아웃 코드들,
유저 입력 프로세싱,
비지니스 로직,
데이터 변환,
화면 전환,
생명주기,
콜백처리(델리게이트 등),
네트워크 통신...
Controller 혼자 몸집이 비약적으로 커지게 된다. (Massive View Controller)
이를 해결하기 위해, "Controller의 역할을 덜어주자!"고 만들어진게 MVP 이다.
•
MVP 패턴
ViewController를 View로 취급하고, Model은 그대로 나둔 뒤, 중계자 역할로 Presenter를 추가하였다.
VC는 꼭 VC에서 처리해야하는 것들 ( 생명주기, 화면 전환, 콜백처리 등 )만 처리하게 나두고,
나머지는 모두 Presenter로 위임하였다.
하지만, Presenter가 view를 업데이트 하는 방식에서,
Presenter가 weak로 View를 소유하고, View에 있는 요소에 직접 접근하여 업데이트한다.
( View를 업데이트 하는 소스가 Presenter에 대부분 속해있다는 뜻 )
따라서, View가 하는 역할이 거의 없다.
또한, Presenter와 View가 서로 소유한다는 것은 높은 의존성을 뜻하며,
이는 개선할 여지가 있다는 뜻이다.
MVVM 의 개념의 기초는 PM(Presentation Model - 마틴파울러의 제안)의 기반으로 만들어 졌다. PM 은 View에 렌더링에 필요한 데이터를 가지고 있는 개체이고, View 는 PM 의 데이터를 기반으로 렌더링한다. PM 의 중요한 포인트는 PM 이 들고 있는 데이터와 View는 항상 동기화가 되어야한다는 것. 여기서 후에 PM 을 ViewModel 이라는 이름으로 명명하면서 MVVM이 탄생했다.
전체 작업을 UI 로직 작업 과 비즈니스 로직 작업으로 나눌 수 있다. 이렇게 나누어진 작업을 디자인에 특화된 UI 개발자는 UI쪽을 담당하고, 비즈니스 로직에 특화된 개발자는 나머지 부분을 담당할 수 있도록 하기 위해서 나뉘어있다.
•
장점 :
1.
독립적인 모델을 만들고, 뷰모델은 어댑터 역할을 하며, 모델 코드의 간섭을 줄인다.
2.
개발자는 뷰를 사용하지 않고, 뷰모델과 모델에 대한 단위테스트를 만들 수 있다.
3.
상태와 동작이 뷰모델에 있으므로, UI 수정이 유연하다.
4.
디자이너와 개발자는 독립적으로 , 동시에 작업할 수 있다.
