MVVM이 필요하다고 생각한 이유
흔히 UIKit 에서 사용하는 MVC 패턴은 Model - ViewController 로 ViewController러 내부에 모든 비즈니스 로직과 뷰가 들어가게 된다.
이 경우에 ViewController의 코드가 굉장히 지저분해지고 뷰의 재사용성이 없다.
또한 ViewController 하나에 모든 로직과 뷰가 의존하기 때문에 테스트 코드를 작성하기에도 매우 까다롭다는 단점이 있었다.
특히 저번 프로젝트에서 Firebase와의 데이터 연동 작업에서 테스트 코드를 작성하지 못하여 불필요하더라도 앱의 전반적인 흐름을 따라가면서 테스트를 했던 적이 있다.
여기서 느꼈던 단점은 우선 테스트할 부분 외적으로 시간이 오래걸린다.
또 오류가 발생하여도 정확하게 내가 테스트하려고 했던 부분의 오류인지 모를 수 있다는 것이다.
따라서 Model ↔ View ↔ ViewModel 패턴을 활용하여 로직과 뷰의 분리 및 테스트 코드 작성을 위한 아키텍쳐 패턴을 공부해보려고 한다.
MVVM이란
Model
데이터 구조를 정의하는 부분, 정의한 데이터 구조를 ViewModel에 알려준다.
이때 View는 Model을 모른다.
모른다는 의미는 ‘Model이 View와 바로 이어지지 않는다.’ 는 의미이다.
ViewModel
사용자가 View에서 이벤트를 발생시키면 처리하는 역할을 한다.
또한 Model의 읽기 쓰기 삭제 작업을 수행한다.
View
사용자가 이벤트를 발생시킬 수 있고 발생한 이벤트를 ViewModel에 알려준다.
View는 ViewModel이 가지고 있는 상태값을 관찰하고 이에 맞게 변경된다.
ViewModel에서 가공한 데이터를 보여준다.
사용할 API
News API – Search News and Blog Articles on the Web
의 API를 활용하여 뷰에 뉴스 제목, 내용을 보여주는 테이블뷰를 만들어볼 예정이다.
아직까지 정확하게 MVVM의 구현방식이 와닿지는 않았지만 프로젝트를 구현하면서 더 공부할 예정이다.
새롭게 알게된 점
사이드 프로젝트를 하던 중
FireStore에서 받아온 json 데이터를 Model에 파싱하는 과정에서 나오는 로직들이 어느 구간에 들어가야 하나 라는 고민이 있었다.
내가 MVVM 에 대해 공부하면서 알게된 바로는 View의 이벤트와 관련이 없는 로직은 Model에 들어갈 수 있다고 알고 있었기 때문에 json을 파싱하는 과정에서의 로직들이 Model에 들어가야 하는 줄 알았다.
그러나 같이 프로젝트를 진행하는 팀원께 여쭤보니 Model에 들어가는 로직은 이미 Model의 데이터가 구현이 된 상태, 즉 파싱이 된 후에 더 이상 바뀌지않는 로직들이 들어가게 된다고 알려주셨다.
또한 이러한 Model에 들어가는 로직들을 ViewModel에서 사용한다. 라고도 알려주셨다.
따라서 Model을 구성하기 위한 데이터를 파싱하는 로직은 네트워크와 도메인 사이에 있는 유틸리티 라고 생각하면 될 것 같다.
참조
[Design Pattern] MVVM(Model - View - ViewModel) 패턴이란? (feat. Swift)
