MVVM
Model + View + ViewModel
Model
데이터와 관련된 코드를 담고 있다. 데이터를 담아두기 위한 구조체, 네트워크 로직, JSON 파싱 코드를 가진다.
struct Person {
let name: String
var age: Int
init(json: JSON) {
name = json["name"].stringValue
age = json["age"].intValue
}
}
// using library 'SwiftyJSON'View, ViewModel 계층을 전혀 신경쓰지 않아도 된다. 데이터를 어떻게 저장할지만 생각하면 된다.
View
유저에게 보여지는 앱의 UI에 대한 코드를 담고 있는 계층이다. View의 각 컴포넌트에 대한 정보를 담고 어느 위치에 어떻게 배치될지 작성되어 있다. View는 디자인적 요소에 더불어 ViewModel로부터 데이터를 가져와 어떻게 배치할 지, 특정 사황에 따라 ViewModel의 어떤 Method를 이용할 지에 대해서도 담고 있다.
MVC와 마찬가지로 View는 재사용성이 강조되며, 컴포넌트를 잘 설계하여 중복된 코드를 줄이는 것이 중요하다.
MVVM 패턴에서 View는 Model을 직접 소유하지 않고, ViewModel로부터 받아와서 정보를 넣어주는 방식이 일반적이다.
ViewModel
앱의 핵심적인 비즈니스 로직을 담고 있는 코드의 계층이다. MVC 패턴의 Controller와 비슷한 역할. View와 Model의 사이에서 View의 요청에 따라 로직을 실행하고, Model의 변화에 따라 데이터를 처리하여 View를 refresh한다.
Model에 변화가 생기면 View에게 notification을 보내는 역할을 한다. 또한, View로부터 전달받는 요청을 해결할 비즈니스 로직을 담는다. ViewModel은 UI 관련 코드로부터 완전히 분리되어있고, 따라서 ViewModel 파일에는 SiwftUI같은 UI 프레임워크를 import하지않아도 된다.
동작 과정
- 유저의 Action들은 View를 통해 입력된다.
- View에 Action이 들어오면, Command 패턴으로 ViewModel에 Action을 전달한다.
- ViewModel은 Model에게 데이터를 요청한다.
- Model은 ViewModel에게 요청받은 데이터로 응답한다.
- ViewModel은 응답받은 데이터를 가공해 저장한다.
- View는 ViewModel과 Data Binding해 화면을 표시한다.
Why MVC → MVVM ?
iOS 개발에서 MVC에서 MVVM으로 넘어가는 추세인 이유는?
기존에 많이 사용한 프레임워크인 UIKit는 MVC 패턴을 기반으로 만들어졌다. (ViewController라는 이름부터 Controller 단어가 붙어있다.) 하지만 비교적 최근에 나온 애플의 SwiftUI는 MVC가 아닌 MVVM 패턴을 기반으로 한다.
MVC와 MVVM는 어떤 차이일까?
UIKit의 주인공은 ViewController : UIKit의 MVC에서는 ViewController가 거의 모든 역할을 맡는다. ViewController 단위로 한 화면이 구성된다. Controlloer는 View 계층, Model 계층을 모두 가지며 Model의 Notification이나 View가 유저의 상호작용을 전달하는 방식도 모두 Delegation 방식을 통해 ViewController가 맡고 있다.
SwiftUI의 주인공은 View : View가 ViewModel을 소유하고, ViewModel이 Model을 소유하는 방식이다. Controller 단위로 화면이 구성되지않고 화면을 주도하는 것은 View이다. 각 View가 필요한 비즈니스 로직들을 ViewModel에서 가져오 사용하는 구조다.
따라서 View와 Model을 모두 알고 있었어야 하는 Controller와 달리, ViewModel은 View에 대해서 알고 있을 필요가 없다.
VC의 문제점과 그 문제를 해결하는 ViewModel
UIKit의 ViewController는 온전히 MVC의 Controller 역할만을 맡고있지 않다.
ViewController는 비즈니스 로직말고도 View에 대한 설정, 수정 등 코드를 가지고 있다. 이럴 경우 View와 Controller 계층을 제대로 분리하지 못한다는 단점이 있다. 안그래도 View, Model의 역할까지 떠안고 있는데, View 계층에 해당하는 코드까지 일부 담당해야 하니 ViewController 코드의 길이가 길어지고 복잡해질 수 밖에 없다.
하지만 ViewModel은 비즈니스 로직만 갖고 있도록 깔끔하게 분리된 계층이기 때문에, ViewController만큼이나 코드 길이가 길어질 필요가 없다. View 입장에서는 필요한 비즈니스 로직을 담은 ViewModel을 해당 화면의 니즈에 따라 골라 사용하기만 하면 되는 입장이 된다.
이렇게 각 계층이 더욱 모듈화되면 테스트 또한 용이해진다. 원래는 View와 Controller가 너무 밀접해 테스트가 어려웠지만, 아예 View와 ViewModel로 분리하면서 mock이 편하고, 로직을 테스트하기 쉬워진다는 장점이 있다.
출처
