iOS Design Pattern (MVC, MVVM)
보통 프로젝트를 하면서 한 곳(ex. ViewController) 에 너무 많은 역할을 하는 코드들이 있으면, 코드의 가독성을 방해하고 여러 팀원들끼리 협업도 힘들어 진다. 해외에서는 이런것을 ‘Massive View Controller’ 즉, View Controller 한곳에 방대한 역할을 하는 코드들이 많다는 뜻이다.
이 문제에 대한 대안으로 여러가지의 iOS Design Pattern (아키텍처 패턴) 이 있다.
- MVC
- MVVM
- MVP
- Viper
- ...
1. MVC 패턴
Model(모델), View(뷰), Controller(컨트롤러) 로 구성.
Model에서는 애플리케이션에서 사용할 데이터들을 관리하고, View는 유저 인터페이스를 표현 및 관리한다. Controller는 View와 Model의 다리 역할을 해 View의 입력을 Model이 반영하고, Model의 변화를 View에 갱신하는 역할을 한다.
하지만 애플의 MVC 패턴은 기존 MVC 패턴과 좀 다르다.
View와 Controller 가 강하게 서로 연결되어 있고 Model 과 직접적으로 통신한다. 따라서 View Controller 에 모든 역할을 하는 방대한 코드가 생기게 되고 한곳에만 코드가 길어지게 되는 것이다.
2. MVVM 패턴
Model(모델), View(뷰), ViewModel(뷰모델) 로 구성. Controller 는 View(뷰) 에 포함이 된다.
View(뷰) 는 ViewModel(뷰모델) 을 소유하고 있고, ViewModel(뷰모델)은 Model(모델) 을 소유하고 있다.
View와 ViewModel 사이에 Binding(바인딩-연결고리)가 있다. ViewModel은 Model에 변화를 주고, ViewModel을 업데이트하는데 이 바인딩으로 인해 View도 업데이트 된다. ViewModel은 View에 대해 아무것도 모르기 때문에 테스트가 쉽고 바인딩으로 인해 코드 양이 많이 줄어든다.
즉, ViewModel 은 Model 에서 가져온 데이터를 가지고 View 에 보여줄 데이터로 가공(연산 로직) 을 하고 View 에서는 ViewModel 의 데이터를 보여주기만 하면 되는것이다.
이런식으로, 로직이 구분됨에 따라서, 디버깅이 용이해 질 것이다. 디버깅 뿐만아니라 많은 사람이 이러한 약속을 통해 코드를 구성한다면, 다른사람이 작성한 코드를 보더라도, 커뮤니케이션이 용이할 것이다.
하지만 단점도 있다.
- 화면이 상대적으로 단순하다면, MVC로 구성하는 것 보다 MVVM으로 구성하는 수고가 더 든다.
- 데이터 바인딩에 대한 수고가 든다.
- MVVM은 유명하지만, 사람마다 생각하는 MVVM이 다르다. 이로 인해 미스커뮤니케이션이 발생할 우려가 있다.
이러한 MVVM 디자인 패턴은 RxSwift 와 같이 자주 쓰이는 패턴이다.