Design Pattern - MVMM

MVVM

저번에 설명했던 MVC패턴과 마찬가지로 앱개발에 자주 사용되는 디자인 패턴중 하나이다.
다만 현재 내가 주로 사용하는 프레임워크인 UIKit는 MVC패턴을 주로 기반으로 하는 반면,
MVVM패턴은 SwiftUI프레임워크에서 주로 사용하는 디자인 패턴이라고 한다.
이번에 작게 개인적으로 진행하게된 프로젝트가 UIkit프레임워크를 기반으로 하고 MVMM패턴을 채택한 프로젝트라, 겸사겸사 MVMM에 대해 먼저 알아보기로 하였다.

MVVM은 MVC 의 C에 해당하는 Controller를 빼고 대신 ViewModel을 추가한 패턴이다.
ViewModel 또한 Controller처럼 View와 Model사이의 중간역할을 한다.

하나씩 설명해보자면

• Model
  MVC에서의 그것과 마찬가지로 실제적 데이터에 해당하는 부분이다.
  데이터를 담아두기 위한 구조체, 네트워크 로직, JSON 파싱 부분도 해당된다.
  MVC에서와 마찬가지로 Model은 View와 ViewModel에 대해 알지못한다.
• View
  역시 UI에 관한 부분이다.
  유저 인터렉션을 받고, 받을 시 ViewModel에 요청한다.
• ViewModel
  앱의 핵심적인 비즈니스 로직을 담고있으며, UI의 동작 및 상태를 관리한다.
  MVC의 Controller와 비슷한 역할을 하며, 마찬가지로 View와 Model 사이 역할
  View의 요청을 받으면 필요한 데이터를 Model에 요청하고, 가지고 있는 비즈니스 로직을 이용해 요청을 해결한다.

 

View는 ViewModel에 의존하고, ViewModel은 Model에 의존하며.
모델은 View와 ViewModel 어떤것에도 의존하지 않는다.
여기서 의존한다는 의미는 import, 참조, 함수 호출과 같은 코드종속성을 의미한다.

 

 

반면 데이터의 흐름은 양방향이다.

 

SwiftUI는 반응형 프레임워크인 만큼, MVMM의 핵심은 데이터 바인딩(Data Binding)에 있는데,
여기서 데이터 바인딩이란. 데이터 제공자와 사용자를 연결시켜 데이터에 변화가 생기면 다른쪽에도 싱크를 맞춰 동기화해주는 방식이다.

---

IOS에서의 MVC패턴은 사실상 View와 Controller가 명확히 구분되지 않고 강하게 연결되어있어
ViewController가 거의 모든일을 하게되는 구조였다.
예를들면 Controller에서 View와 Model 계층을 모두 소유하고있고, Model의 notification, View와의 interaction도 모두 delegation을 통해 VC가 하게되어있다.
그러다보니 ViewController가 지나치게 무거워지고 방대해져 모듈화 하는 의미가 무색해지고 테스트가 어려워졌다.
반면 MVMM패턴의 ViewModel은 비즈니스 로직만 가지고 있도록 깔끔하게 분리된 계층이기 때문에, MVC에서의 Controller 처럼 코드가 방대해지는것을 방지할 수 있다.

 

역시나 찾아보면서 공부하며 이해하는것에는 한계가 있는것같다.
특히 데이터 바인딩이나 ViewModel의 역할등 세세한 부분은, 일단 개념정도만 숙지해두고
프로젝트를 직접 진행하면서 겪어보며 숙달시킬 예정이다.

 

 

참고한 블로그

https://lena-chamna.netlify.app/post/ios_design_pattern_mvvm/

https://medium.com/hcleedev/ios-swiftui%EC%9D%98-mvvm-%ED%8C%A8%ED%84%B4%EA%B3%BC-mvc%EC%99%80%EC%9D%98-%EB%B9%84%EA%B5%90-8662c96353cc

https://www.vadimbulavin.com/modern-mvvm-ios-app-architecture-with-combine-and-swiftui/