[iOS] MVVM 패턴

MVVM 패턴이란?

모델 - 뷰 - 뷰모델, 하나의 소프트웨어 아키텍처 패턴입니다. (* 아키텍처 패턴은 디자인패턴과 비슷하지만 더 넓은 범위에 속하며, SW공학의 다양한 문제를 해결하는데 예를들어 컴퓨터 하드웨어 성능 제한하거나 비즈니스 위험의 최소화 등을 해결할 때 사용된다.)

 

 

Model - View - ViewModel

1. Model

MVC에서의 Model과 마찬가지로 데이터와 관련된 코드를 담고 잇다. 데이터를 담아두기 위한 구조체들은 물론, 네트워크 로직, JSON 파싱 코드를 담고 있다.

비지니스 로직에서 사용하는 근본 데이터.

 

2. View

앱의 UI에 대한 코드를 담고 있다. ViewModel로부터 데이터를 가져와 어떻게 배치할지, 특정 상황에 따라 ViewModel의 어떤 메소드를 이용할지도 담고 있다.

View는 재사용성이 강조되며, 컴포넌트를 적당히 잘 나누어 중복된 코드를 줄이는 것이 중요하다.

 

3. ViewModel

앱의 핵심적인 비즈니스 로직을 담고 있는 코드의 계층이다. MVC의 Controller와 비슷한 역할을 하고 있다. View와 Model 사이에서 View의 요청에 따하 로직을 실행하고, Model의 변화에 따라 View를 refresh하는 등, 유사한점이 아주 많다.

View로부터 전달받는 요청을 해결할 비즈니스 로직을 담고 있고, UI관련 코드로부터 완전히 분리되어 있기에 SwiftUI같은 UI프레임워크를 import할 이유조차 없다.

 

 

각 계층마다의 로직 및 의존 관계

곰튀김님의 MVVM 강의를 보면, 아래의 6개의 파일들이 존재하고 각 파일들이 하는 역할은 아래와 같다.

1. Entity : 서버로 부터 받은 원천데이터
2. Repository : Entity를 가져오는 역할
3. Model : 비지니스 로직에서 사용하는 근본 데이터, Service에서 취급하는 데이터
4. Service : 비지니스 로직, 가장 중요한 부분
5. ViewModel : 화면에 보이기 위한 화면 데이터, 화면에 보여진 데이터를 Model로부터 만들고 가지고 있는 것
6. View : 화면, Service가 처리한 데이터 Model을 화면용데이터(VM)로 변환해 화면에 그려냄

 

의존관계

View        Service      Repository

⬇️    ↗️   ⬇️     ↗️      ⬇️

VM           Model          Entity         —> Data Model들

 

- 화살표 방향으로 일관성있도록 의존성을 유지하려면, View는 VM을 사용하기만 해야할 뿐, VM이 View를 알아서는 안된다.

- 그러다보니 View가 VM의 데이터 변경을 스스로 알아챌 필요가 있고 그래서 DataBinding이 필요해진다.

- 결국 데이터를 용도에 따라 구분해 놓고 그 의존관계를 일관성이 있게 유지하려면 DataBinding이 등장할 수 밖에 없다.

 

 

결론

1. MVVM 이 DataBinding 자체를 말하는 것이 아니다.
2. MVVM 에서 VM에 모든 비지니스 로직이 있어야 하는 것이 아니다.
   • 비지니스 로직은 Service 같은 곳에 있어야 하고
   • VM에서는 화면용 데이터를 갖고 있는것,
   • Model 을 View용 Model 로 변경하는 정도의 로직 만 있으면 된다.
3. MVVM의 데이터 의존관계를 일관성있게 유지하기 위해서 VM은 V를 알면 안된다.
4. MVVM 의 DataBinding를 위해서 반드시 RxSwift 같은 것을 사용해야만 하는 것은 아니다.

 

iOS개발이 MVC에서 MVVM으로 넘어가는 이유

기존에 우리가 많이 사용한 프레임워크인 UIKit은 MVC패턴을 기반으로 만들어졌다. 하디만 최근 유명한,,,, SwiftUI는 MVC가 아닌 MVVM패턴을 기반으로 한다.

 

UIKit에서는 ViewController가 주인공이고, SwiftUI에서는 View가 주인공이다.

UIKit에서는 ViewController가 거의 모든 역할을 하고 있고, VC단위로 화면들이 구성되어 있다. Controller는 View,Model 계층을 모두 소유하고 있으며 Model의 notification도, View가 유저 상호작용을 전달하는 방식도 모두 delegation을 통해 VC이 다 떠맡고 있다.

 

SwiftUI에서는 View가 ViewModel을 소유하고, ViewModeldl Model을 소유하는 방식이다. Controller 단위로 화면을 구성하는 것이 아니라, 해당 화면을 주도하는 것은 View다. 따라서 View와 Model을 모두 알고 있어야하는 Controller와 달리, ViewModel은 View에 대해서는 알고 있을 필요가 없다.

 

또한 내가 항상 궁금했던, UIKit은 MVC가 명확하게 분리된거 같지 않다는 궁금즘 또한 해결했다.

UIkit의 ViewController는 비지니스 로직 말고도 View에 대한 설정, 수정 등 코드를 가지고 있다. 이럴경우 View와 Controller 계층을 제대로 분리하지 못한다는 단점이 있다. 안그래도 Controller가 View, Model의 역할까지 떠안고 있는데 View 계층에 해당하는 코드까지 일부 담당해야하니 VC의 길이가 길어질 수 밖에 없다.

 

MVVM 구조를 사용할 경우, View 입장에서는 필요한 비즈니스 로직을 담은 ViewModel을, 해당 화면의 니즈에 따라 골라서 사용하기만 하면 된다. 각 계층이 더욱 모듈화되어 테스트가 용이해진다. 그렇다고 완벽한 디자인 패턴은 아니다. 장단점이 있으니 적절히 활용을 하면 된다.. MVVM의 핵심은 DataBinding인데 따로 공부해서 올릴예정이다.. 여기

 

 

MVC, MVP, MVVM 의 차이

 

 

[참고사이트들]

iOS - SwiftUI의 MVVM 패턴과 MVC와의 비교

https://www.youtube.com/watch?v=bjVAVm3t5cQ

https://github.com/iamchiwon/RxSwift_In_4_Hours

https://www.youtube.com/watch?v=M58LqynqQHc

https://github.com/iamchiwon/mvvm_final