MVVM의 개념과 나오게된 배경

MVC : 역할에 따라 구분해서 프로그램을 나눠보자

MVP : 화면과 로직을 분리하자.

MVVM : 화면은 알아서 그리렴. 나는 데이터만 바꿀테니

 

MVVM이 나오게 된 이유

MVC에서 Controller는 비지니스 로직도 처리하고 UI도 처리하고 혼자 일을 다해서 Controller가 힘들어졌다..

그래서 MVP의 Presenter라는 것이 나왔고,

 

MVP에서 로직처리는 Presenter가( input들어오면 무조건 프레젠터한테 알려줘! / 프레젠터는 UI와 상관이 없어졌고, 뷰와 모델 분리)

뷰와 모델사이에서 모든상황에 중개자 역할을 했다. 이렇게 뷰와 모델을 분리하게 되었으나 Presenter 또한 중개를 혼자하니 Presenter도 힘이 들었다. Presenter 뷰와 일대일의 관계로 뷰를 만들때마다 Presenter를 매번만들어야 했다.

이것 또한 비효율적이라고 생각한 똑똑한 사람들이 MVVM이라는 것을 만들었고 VM를 공통처리할수 있게 하였다.

ViewModel

• 뷰모델과 뷰는 일대다의 관계
• 모델은 데이터의 변경이 있을시에 뷰모델에게 알린다.  뷰 모델은 모델을 소유하고 있고 뷰 모델이 모델에 대해서 들여다 볼수 없다.
• 유저가 뷰에게 액션을 취할때 모델을 변경하거나 뷰모델에게 결과를 알리고 뷰를 갱신한다.( 뷰는 구독하고 있다가 알아서 화면을 그린다.)
• 뷰와 뷰모델이 동기화 되어 있는상태( 데이터 바인딩이 되어 있는 상태)
• 앱의 핵심적인 비지니스 로직을 맡고 있는 코드의 계층
• UI관련코드와 분리되어있으며 로직 담당이다.

MVVM의 장점

모듈화가 가능 -> 모듈화가 잘되면 유닛테스트에 용이

뷰와 모델의 간의 종속성이 줄어들어 소스코드를 보기가 편하다.

뷰를 직접 조작하지 않아 영역이 독립적이다.

모듈화가 되어있기 때문에 문제있는 부분만 고치면되서 유지보수가 용이하다.

MVVM의 단점

간단한 프로토타입을 만들때는 과하다.

큰 프로젝트의 경우 데이터를 바인딩하고 시작하기 때문에 메모리 사용량이 증가한다.

구현구조가 복잡하고 설계가 쉽지 않다. 설계를 잘 못한다면 의미가 없어진다.