MVVM 관련 공부는 했었는데 MVC에 대해서는 모르는 거 같아서 이번에는 MVC에 대해 알아볼게요
MVC
MVC는 Model-View-Controller의 약자로 UIKit에서 오래 기본처럼 사용되던 아키텍처 패턴이에요. Model은 데이터와 비즈니스 규칙, View는 화면 표시, Controller는 사용자 입력을 받아 Model과 View를 연결하죠
장점
MVC 패턴의 장점은 다음과 같아요
- 역할 분리
Model(데이터/비즈니스), View(표현), Controller(입력/흐름)를 나눠서 코드 이해가 쉬워져요. - 변경 영향 축소
UI 수정은 주로 View, 데이터 규칙 수정은 Model 쪽에 집중돼서 수정 범위가 줄어요 - 병렬 개발 용이
디자이너/프론트는 View, 로직 담당은 Model을 중심으로 동시에 작업하기 좋아요 - 재사용성 향상
같은 Model을 여러 View에서 재사용하거나, 같은 View에 다른 데이터 소스를 붙이기 쉬워요 - 테스트 분리 가능
Model, View, Controller의 로직을 나눠서 테스트하기 쉬워요 - 구조적 확장성
작은 앱이 커질 때 “어디에 코드를 둬야 하는지” 기준을 제공해서 무질서해지는 걸 늦춰줘요
한계
처음 의도는 UIView가 View역할을 담당했고, UIViewController가 Controller역할을 담당하는 거였어요.
하지만 UIViewController가 화면(View) 생명주기 관리, 사용자 입력 처리, 분기/전환 같은 UI 흐름 제어를 함께 맡게 돼있어서 View + Controller의 역할을 하게 됐어요. 유지보수를 쉽게 하는 설계 원칙인 SOLID 원칙에 대해서는 들어보셨죠? 그 중에 S(SRP, 단일 책임 원칙)은 말 그대로 책임을 한 가지로 나누는 원칙인데 View와 Controller의 역할을 같이 하다보니 어기게 된거에요.
네트워킹, 상태관리, 포맷팅, 비즈니스 로직까지 UIViewController에 몰리기 쉬워 Massive ViewController 문제도 발생하고 테스트가 어려워지고 화면 복잡도가 커질수록 재사용성과 변경 대응력이 떨어졌어요.
이를 해결하기 위해 나온게 MVVM 패턴이었던거에요. 기존에 컨트롤러 역할을 하던 UIViewController를 UIView와 같이 View역할만 하게 하고 ViewController에 몰리던 상태/표현 로직을 별도 타입(클래스/구조체)에 옮겨 ViewModel 역할을 담당하게 했죠
