MVVM 패턴

mvvm은 view를 비즈니스로직이나 model로 부터 분리시켜 view가 어느 특정 모델에 종속되지 않도록 해주는 패턴이다.

: Model + View + ViewModel

구성요소

Model
- 데이터, 네트워크 로직, 비즈니스 로직 등을 담고, 데이터를 캡슐화하는 역할
- view, viewModel 은 신경쓰지 않는다.
- 데이터를 어떻게 가지고 있을지에 대해서만 신경쓰고, 어떻게 보여질지는 신경쓰지 않는다.
- MVC 와 유사.
View
- 사용자가 화면에서 보이는 것들에 대한 구조, 배치 등을 다룬다.
- model 을 직접 알고 있으면 안 된다.
- viewModel 로부터 가져온 데이터로 표현한다.
- 사용자로부터 이벤트를 수신하고, 그에 대한 처리를 viewModel에 넘긴다.
ViewModel
- view로 부터 전달받은 요청을 처리할 로직을 담고 있다.
- model 에 변화가 생기면 view에 notification을 보낸다. (데이터변화를 view가 알 수 있게)
- view와 model 사이의 중계자 역할. presentation logic을 처리한다.
- MVC의 controller와 유사.
ViewController
- View Life-Cycle을 처리하고, 데이터를 UI 구성요소에 bind할 때만 viewModel, view와 통신한다.

구성요소간의 의존성

MVC
- 기본적으로 view와 model은 다른 구성요소들을 알지 못하며, controller는 view와 model을 모두 알고있는 형태로 구현되어야 한다.
MVVM
- view는 viewModel을 알고 있고, 소유한다.
- viewModel은 model만 알고 있도록 구현한다.
- model은 다른 구성요소를 알지 못하도록 마들어야 한다. (= MVC와 같음)

view가 데이터를 보여주는 방식

MVC
- model에 view를 Observer로 둥록하여 데이터를 설정하는 방식 (model이 view를 알고 있는 형태)
- viewController가 model의 변경을 알아차리고 직접 view에 데이터를 설정해주는 방식(aapple의 MVC)
MVVM
- view와 viewModel의 binding을 통해 스스로 데이터를 보여준다.
- view에 데이터를 보여주기 위한 설정 책임을 view 스스로가 가진다)

user interaction

MVC
- 사용자 상호작용에 대해 view가 controller에 처리를 부탁하기 위해 delegate pattern, target-action 등을 사용
MVVM
- view와 viewModel을 알고 있으므로 필요할 때 viewModel의 메서드를 호출하는 방식으로 구현 가능 (필수는 아님)

ViewController 가 view에 대한 설정뿐만 아니라 View Life-Cycle 관리 등등 view와 밀접한 관계이다.
MVVM에서의 viewModel은 view를 알지 못하며 view``를 설정하는 코드가 전혀 안들어간다. (데이터 변경에 대한 view업데이트는 온전히view`의 책임인 것)
UIKit - MVC : event driven
- 이벤트에 따라 특정 로직이 실행되고, 그에 따라 view가 바뀐다.
SwiftUI - MVVM : data driven
- 데이터의 변경에 따라 로직이 실행도고, 그에 따라 view가 바뀐다.

Distribution (책임 분배)
- view는 바인딩을 통해 viewModel로 부터 보여줄 데이터를 가져온 뒤 직접 업데이트한다.
- MVC에 비해 controller의 역할이 줄어든 것
Testability (테스트 용이성)
- viewModel은 view에 대해 모른다.
- 그렇기에 viewModel을 쉽게 테스트할 수 있도록 해준다.
easy og use (사용 편리성)
- view를 수동으로 업데이트하는 MVP보다 바인딩을 사용하는 경우 MVVM이 훨씬 간단하다.
  (100% 언제나 그렇지는 않음. 간단한 프로젝트를 하는 경우는 굳이 MVVM을 사용하면 더 복잡해보일 수 있다.)

참고 링크