[Stanford] MVVM

MVVM

코드를 관리하기위해 기존 UIKit에서 자주 사용하던 MVC 패턴과 다른 디자인 패러다임

 

Model - View - ViewModel

스유에서 MVVM은 빼놓을 수 없다.

 

View - User Interface Code

유저에게 앱이 "어떻게 보여지고 있는가?"

Return a UI that reflects the state of the Model

Immutable

 

* Stateless

* Declared

* Reactive

 

 

Model - 백엔드나 앱 로직 관련

Data + Logic

- UI Independent

-> 스위프트 파일에서 SwiftUI 임포트 안함.

Model is what your application actually is and does

 

명령적 프로그래밍

-> UI를 그리기 위해 함수를 순차적으로 실행함 (과정)

vs

선언적 프로그래밍

-> UI를 실질적으로 그리는 body var 부분만 보면 됨(정확히는 body var에 접근하는 코드)

 

ViewModel

어떤 변화가 생겼을 때, 전체 UI를 전부 rebuild 하는 것이 아니라, 변화와 관련된 부분만 리빌드 하도록

ViewModel's job : bind the View to the Model, so the changes in the Model cause the View to react and get rebuilt.

뷰와 모델 사이의 interpreter라고 이해할 수도 있음

(모델이 엄청 복잡하다면.. 뷰 모델을 거쳐서 최대한 뷰로 간단하게 전달되도록)

ex. SQL database Model에서 관련 데이터를 받아와 뷰에는 배열 형식으로 전달하기

'뷰가 원하는 형식으로!"

 

View must alays get data  from the Model by asking for it from the View Model.

 

뷰모델은 모델의 변화를 항상 알아차림.

-> 변화가 생겼다라는 신문을 발간함(비유임)

 

뷰는 자동적으로 신문을 관찰(구독하고) 관련 데이터를 받아와 필요한 부분을 리빌드함

 

 

뷰에서 일어난 이벤트(ex.터치,스와이프)는 모델에서 어떻게 알아차리나?

 

참고

https://github.com/iamchiwon/RxSwift_In_4_Hours/blob/master/docs/mvc_mvp_mvvm.jpeg

MVC

역할에 따라 구분을 해보자(뷰, 모델, 중간 관리자인 컨트롤러)

하지만 뷰컨트롤러가 입력도 받고 온갖 처리를 다 하다보니.. 비대해지는 문제가 있었음.

 

MVP

따라서 등장한 것이 MVP

뷰컨트롤러가 뷰와 같이 있음 -> Input처리를 뷰에서 담당함

Presenter는 View가 뭐 그릴지만 알려줌

(유닛 테스트를 위해 화면과 로직을 분리) 하지만 View마다 Presenter가 있어야 하는 단점 있음.

 

MVVM

ViewModel은 데이터만 가지고 있음.

View에게 직접 이래라 저래라 하지 않음..

그냥 데이터가 바뀌면 어 데이터 바꼈네~~ 화면은 알아서 니가 그리렴~

그러면 View가 ViewModel을 지켜보고 있다가(구독 개념) 알아서 바꿔 그림

 

 

일단.. 프로젝트에 직접 적용을 해봐야 더 이해가 될 것 같다.