[Swift] MVVM 패턴

MVVM(Model - View - ViewModel)

MVVM(Model-View-ViewModel)은 소프트웨어 아키텍처 패턴 중 하나로,

Model, View, ViewModel이라는 세 가지 역할로 구성됩니다.

MVP(Model-View-Presenter) 패턴과 유사하지만, MVP의 Presenter 역할을 ViewModel이 대신합니다.

MVVM은 UI와 비즈니스 로직을 명확하게 분리하여 관리하고, 코드 유지보수성을 높이는 장점이 있습니다.

1.1 아키텍처 패턴 구조

Model - 일반적으로 앱에서 사용하는 데이터 모델이나 API와 상호 작용하는 객체입니다.

• 비즈니스 로직이 모델에 포함됩니다.

View - UI와 관련된 코드입니다. 

• Command Pattern을 이용하여 뷰모델을 구독하며(Protocol), 뷰모델에서 받아온 데이터를 바인딩하여 뷰에 처리합니다.

ViewModel - 뷰와 상호작용하는 논리를 캡슐화합니다.

• 뷰는 ViewModel을 구독하며, ViewModel은 Model과 상호 작용하여 데이터를 업데이트합니다.
• 이를 통해 ViewModel은 View와 Model 간의 종속성을 분리하여 코드의 유지보수성을 높입니다.

1.2 Clean Architecture with MVVM

MVVM 설계 방식에 따라 설계했을 시 뷰모델의 역할이 모호해지고, 그로 인해 뷰모델이 Presenter처럼 다른 계층과 밀접한 관계를 가지게 되어 모든 일을 맡아서 처리하는 상황이 발생합니다.

이를 방지하기 위해 뷰모델의 역할을 줄이고, UseCase + Entity(with Business Logic)으로 역할을 분배하여 계층구도를 명확히 하여 유지보수를 높게 하기 위한 방법입니다.

1.3 Clean Architecture with MVVM 계층 구조

External Interfaces

• 안쪽의 원과 통신할 연결 코드 이외에는 별다른 코드를 작성하지 않는 계층입니다.
• 이 계층에는 네트워크(AF, URLSession), DB(CoreData, UserDefaults) 등이 포함됩니다.

Data Layer

• Actor가 필요로 하는 데이터 모델을 의미합니다.
• 이 계층에는 특정 도메인에서 사용되는 struct 모델, 예를 들어 네트워크 통신시 매핑할 Codable 모델 등이 포함됩니다.

Domain Layer

• Actor가 Entity를 원하는 데, 이 값은 계산되거나 특정 로직에 의해서 얻어지므로 Actor가 원하는 Entity를 얻어내고 있는 로직을 의미합니다

Presentation Layer

• Entity 데이터를 그대로 표현(‘present’)하는데 필요한 계층입니다.
• 이 계층에는 Coordinator(MVVM-C 패턴), View, ViewModel, Behaviors(특정 view의 event에 관해 적용되는 UI) 등이 포함됩니다

<The Clean Architecture Diagram>

1.4 Clean Architecture with MVVM 의존관계 설계 원칙

• Clean Architecture는 소프트웨어 시스템의 구성 요소들이 서로 어떻게 의존하고 있는지에 대한 원칙입니다.
• MVVM 패턴에서 Clean Architecture를 적용하기 위해서는, 잘 변하는 것에서 잘 변하지 않는 것으로 의존관계가 되는 것이 이상적인 형태입니다
• 여기서 잘 변하지 않는 계층인 Domain 계층은 비즈니스 로직이나 엔티티를 담당하며, Presentation 계층과 Data 계층이 의존하는 형태로 구성됩니다. Presentation 계층은 사용자 인터페이스를 담당하고, Data 계층은 데이터를 처리하고 저장하는 역할을 합니다.
• 이러한 구조를 유지함으로써, Presentation 계층과 Data 계층의 변경사항이 Domain 계층에 영향을 주지 않도록 하여 시스템을 유연하고 확장 가능하게 만들 수 있습니다.

1.5 MVVM 패턴의 장단점

장점

• 수정, 변경, 제거 등 코드의 다른 부분이 변경되어도 UI의 변동사항은 없습니다.
• 즉, 완벽하게 분리되어 있어서 시스템을 유지보수하기 용이합니다.
• ViewModel에 가짜 Input을 넣어주면 결과값이 나오기 때문에, 유닛 테스트가 쉽습니다.

단점

• 설계 난이도가 높습니다. MVVM 패턴은 잘못된 설계가 적용될 경우 시스템의 복잡성을 증가시키고 유지보수를 어렵게 만듭니다
• 프로젝트가 커질 경우, ViewModel이 거대해질 수 있습니다. 이러한 상황을 Massive ViewModel이라고 합니다.(클린 아키텍처 미적용 MVVM 입니다.)
• 틀은 같지만, 사람마다 설계하는 방법이 전부 달라서 정답이 없습니다. 이는 설계가 제멋대로임을 의미합니다
• 작은 프로젝트의 경우 MVVM 설계 시 불필요한 설계가 될 수 있습니다. 반면, 너무 큰 프로젝트의 경우 데이터 바인딩에 많은 메모리를 소모하게 됩니다.

1.6 설계하면서 느낀 점

• 클린 아키텍처를 적용하지 않고 비즈니스 로직을 ViewModel에 구현한 MVVM은 MVC와 별 다를 것이 없다고 생각합니다.
• ViewModel에 비즈니스 로직을 구현한 예제 소스가 많은데, MVVM 패턴에서는 비즈니스 로직을 ViewModel에 구현해서는 안 된다는 것을 강조하고 싶습니다.
• 그렇다면 비즈니스 로직은 어디서 구현해야 할까요? 모델 계층에서 구현하는 것이 바람직합니다.
• 뷰모델은 오로지 뷰에서 업데이트 요청을 받으면 그 요청을 모델에 전달하고, 모델에서 가공된 데이터를 뷰에 뿌려주는 역할만을 해야 합니다.
• 다양한 MVVM 패턴을 살펴보면서 각각의 장단점으로 인해 혼란스러워하는 분들이 많다는 것을 알게 되었습니다. 하지만 핵심 구조를 잘 파악하면 설계하는 데 어려움이 많이 줄어들 것이라고 생각합니다.