iOS MVVM 패턴

Data Binding: 두 데이터를 묶는 것으로, 한 쪽이 변화가 있으면 다른 쪽도 자동 갱신으로 이루어 지는 것

• 종류
  • KVO
  • Delegation
  • Clouser(콜백)
  • NotificationCenter
  • 반응형 프로그래밍 (RxSwift, Combine)
  • Property Observer (didSet, willSet)

역할

Model

• 데이터를 담아두기 위한 구조체, 네트워크 로직, JSON 파싱 코드 등 비즈니스 로직에서 사용되는 근본 데이터를 담고 있는 계층
• View, ViewModel에 대한 의존성이 없기 때문에, 데이터가 어떻게 보여질 것인지에 대해서는 고려하지 않음

View

• 화면 UI를 어떻게 구성할 지에 대한 계층 (SwiftUI에선 View, UIKit에서는 ViewController)
• 사용자로 부터 UI이벤트가 일어나면 이에 대한 비즈니스 로직 처리를 ViewModel에 요청
• Data Binding을 통해, ViewModel의 데이터를 관찰하고 있다가 해당 데이터가 변화가 있다면, 직접 해당 데이터에 대한 UI를 자동으로 변경시킴
• View가 직접 본인의 Life Cycle이나 사용자와의 상호 작용 이벤트를 관리함
• 재사용성이 강조되며, 컴포넌트를 잘 나눠 중복된 코드를 줄이는 것이 중요
• ViewModel를 소유함

ViewModel

• View와 Model 사이에서 앱의 핵심적인 비즈니스 로직을 담고 있는 코드의 계층
• View로 부터 전달받은 요청을 해결할 핵심 비즈니스 로직을 담고 있음
• Model의 데이터 변화에 대해 View에게 Data Binding을 통해 notification을 줌
• View를 소유하지 않으며 View의 Life Cycle이나 사용자와의 UI 이벤트에 대한 처리 하지 않음. 그러므로 각각 다른 View에서 같은 ViewModel을 바라보고 보여지는 방법을 달리할 수 있음 (View : ViewModel = 1 : N 관계)
• Model를 소유함

장점

• ViewModel은 View의 Life Cycle이나 사용자와의 UI 이벤트 처리를 하지 않고 View를 소유하지 않음
  • 테스트하기 용이
  • 재사용성이 높음
  • Controller에 비해 수행해야할 역할이 더 적음

단점

• ViewModel의 비즈니스 로직이 복잡해지면 Controller처럼 비대해질 수 있음
• 간단한 앱에 대대는 MVC보다 시간이 오래걸림

MVC와의 차이점

MVC

1. MVC의 Controller가 View를 소유한채, View의 Life Cycle이나 사용자의 UI 이벤트에 대한 처리를 담당함
2. 또한 Controller는 Model도 소유한 채, Model 데이터의 변경을 알아차리고 View를 갱신 시킴.

결과적으로 Controller 코드 수가 길어지고 테스트하기 힘들어지고 재사용도 어려워짐

MVVM

1. MVVM에선 ViewModel가 View를 소유하지 않음과 동시에 View가 직접 Life Cycle이나 사용자의 UI 이벤트에 대한 처리함
2. Model의 데이터의 변화가 생기면, ViewModel에게 해당 데이터를 전달하고 View는 해당 데이터와의 Data Binding을 통해 직접 UI를 갱신 시킴.

결과적으로 Controller보다 ViewModel의 코드 수가 적어지고 테스트하긴 용이해지고 재사용하기 쉬워짐

 

출처:

https://velog.io/@ictechgy/MVVM-디자인-패턴

https://ios-development.tistory.com/1128

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

https://42kchoi.tistory.com/292

https://hellozo0.tistory.com/370