파이널 프로젝트 이전, 팀 과제를 하면서 네이버 지도 API를 사용하게 됐다.
일상 속 자주 사용하는 API임에도 불구하고 정말 불친절한 경우가 많았는데,
이번 프로젝트에 적용해보려고 씨름을 하다보니 MVVM 관련해서 이전보다 조금은 이해하게 되었다.
관련해서 내용을 정리해본다!
디자인 패턴 (MVVM)
이전에 MVC 패턴 관련해서 정리를 했었는데, MVVM은 MVC에서 한 단계 더 나아간 디자인 패턴이다.
(단 우위에 있다는 이야기는 아닌 듯하다. 단지 한 단계 더 거쳐가는 역할이 있을뿐)
MVVM은 MVC의 역할을 새롭게 제시하는데,
Model, View, ViewModel (+ Controller)로 코드를 정리한다.
Model과 View는 동일하게 유지하되, ViewModel을 통해 View에 뿌려질 데이터를 관리한다. 단순히 ViewController에서 데이터를 뿌리던 과정이 ViewModel이 처리하는 차이인데 어떤 장점이 있는가하면, 내가 느끼기로는 ViewController가 가져야하는 책임의 무게를 덜 수 있게 된다는 점이 가장 크다.
MVC 패턴
MVC 패턴에서 ViewController는 로직처리부터 UI를 그리는 역할까지 모두 한꺼번에 했다.
어떤 코드가 어떤 작동을 해야하는지 처리를 동시에 하다보니 UI를 그리면서 해당 UI에 어떤 데이터를 뿌려야할지 함께 고민을 해야하는 큰 책임이 있었다.
그러다보니 자연스럽게 UI 관련, 비즈니스 로직 관련 코드가 한 파일로 정리가 되고 그렇게 되면서 파일 자체의 규모와 depth 또한 기하급수적으로 높아진 상황이다.
MVVVM 패턴
반대로 ViewModel을 채택하게 되면서 ViewController에서 처리하던 데이터 처리, 로직은 ViewModel로 위임을 하게 됐다. 따라서 View를 그리는 역할은 ViewController에서만 처리하게 됐는데, 이를 통해 UI를 그리는 코드만 담당할 뿐, 그 이상의 책임은 가지지 않게 됐다.
코드 길이 또한 줄어들게 되고 추후 정리하게 될 "데이터 바인딩"을 통해 지속적으로 업데이트 되는 데이터 모델의 변화에 맞춰 View를 업데이트하게 된다.
MVVM이 항상 좋다고 볼 수는 없겠지만 내가 느끼기로 MVVM이 한층 더 UIComponent들과 로직을 구분한다는 점이 들었다. DayWeather만 보더라도 ViewModel안에는 각 view마다 필요한 API 호출 및 메서드들이 들어 있다. ViewController에서는 대체적으로 view를 그리는 함수들만 있기에 나름의 역할 분담을 잘하게 되는 것 같은 기분이다.
하지만 동시에 생각이 드는 건,
1. viewModel의 역할을 잘 수행하고 있는지에 대한 고민
2. MVVM은 왜 탄생했을지에 대한 생각이 들었는데...
1. 현재 viewModel 역할 분담
대량의 날씨 데이터를 singleton weatherDataManager에서 가져오고 있는만큼 필요로 하는 데이터만 아래와 같이 사용하고자 했다.
weatherDataManager
1. 전체 데이터 fetch
2. 필요 데이터 가공 (temperature, city)
FoodViewModel
3. 1차 가공 데이터 재가공 (temperature)
4. reverseGeoCoding으로 좌표 값 → 주소 변환
5. SearchAPI 호출
이렇게 구성하면서 든 생각은 viewModel이 다소 싱글톤처럼 보여지는 느낌도 있었다. 오로지 날씨 데이터만 가공하고 있어서 이런 양상이 보였지만 싱글톤과 달리 viewModel은 오랜 생명 주기를 가지고 있으면 안된다는 점을 알게 됐다!
2. MVVM 탄생 배경
듣기로 SwiftUI를 위해 MVVM 디자인 패턴이 선호되는 방향이라고 보았다.
화면을 이전보다 훨씬 많이 그리고 있기 때문인지에 대한 고민들도 들게된다.
SwiftUI에서는 closure을 더 많이 사용하며 UI를 그리는 방식이나 방법이 조금씩 다르다고 하는데... 걱정이 들면서 동시에 기대도 된다.
