MVC 패턴과 MVVM 패턴에 관한 나의 생각
다양한 아키텍쳐 패턴이 존재한다. 비단, MVC와 MVVM 외에도 MVP.. 등등 ..
근데, 나는 MVC 패턴에서 MVVM으로 갈아타는 그 '일련의 과정'이 왜 다수의 사람들에게 통용되는지 알 거 같다.
처음에 우리는 Xcode를 통해 iOS 개발을 시작할 때, 폴더링에 대한 개념을 MVC로 많이 접하곤 한다.
왜냐. 직관적이다.
Model - View - Controller 뭐랄까. 거시적인 시각으로 봤을 때 세 덩어리기 때문에 얼마나 단순해보이는가.
(내면은 실은 그게 아니거등 .. 직관적이지 못해 ..)
내가 MVC를 배울 적, 나는 아래와 같이 정의내렸었다.
- Model에서 json같은 데이터를 받아오기 위한 데이터 구조를 정의하고,
- Controller에서 받아온 데이터를 가공하고,
- View에서 가공한 데이터를 보여준다 이다.
UI에 대한 개요를 Model 폴더링을 통해 파일들을 다 짜고, ViewController에 거시적인 추합의 과정을 거친다.
그러면 뚝 딱 완성된다.
이랬던 MVC 패턴을 사용하다 보면, 문득 생각이 든다.
'나누는 기준의 잣대가 단순히 시각으로 세 뭉텅이 나누는 거 보다, 코드 저마다 가진 <역할>에 집중을 해야할 거 같은데?'
나만이리 생각하는 게 아니였다 ..
그리고 실로, 대안은 많았다. 다른 아키텍쳐패턴들이 나를 기다리고 있었다.
그 중 MVVM은 정말 딱 적합했다.
왜인고하면,
- 최근 앱스토어 배포를 마친, 프로젝트 <위니>에서 프로젝트의 볼륨이 커지면 커지려할 수록 관리가 불편했다.
(정말 시각적으로 수고를 덜어야하는 데 소요되는 시간이 아까울 따름이었다.) - 유지보수에 지장을 끼친다. 앞선 이유의 연장선이다.
- 가독성의 하락이다. 이 또한 앞선 이유의 연장선이다.
그치만 MVVM을 사용 시 앞선 모든 것들을 해결할 수 있게 된다.
고로, MVC는 사랑을 싣고 MVVM으로 계승한다.
MVVM 개요
- Model에서 데이터 구조에 관한 코드를 기재하고,
- View에서 보편적으로 UI에 관한 코드와 메소드 호출 코드를 적는다.
- ViewModel에서 기존의 UIKit을 import 할 필요도 없이 데이터 update 및 뷰 요소를 업데이트 한다. 로직을 담당한다.
MVVM 장점
MVVM 패턴의 장점은 View - Model - ViewModel 모두 독립적으로 테스트가 가능하다는 것이다.
MVVM 단점
반면 단점은 설계가 어렵다는 것과 뷰에 대한 처리가 복잡해지면 뷰모델도 거대해진다는 것이다.
추후
Rx와 데이터바인딩 하는 것에 관한 플레이그라운드 실습 내용과
API Get 메소드를 통해 네트워킹하는 것을 Xcode 실습 내용을 업르도 할 예정입니다.
https://fitzafful.medium.com/data-binding-in-mvvm-on-ios-714eb15e3913
