MVVM이란?

UI와 비즈니스 로직을 명확하게 분리하여, 개발자가 각 부분에 집중할 수 있도록 한 앱 아키텍처 패턴이다. 개발코드의 가독성과 유지보수성, 재사용성을 향상할 수 있으며, 특정 단위로 테스트를 쉽게 작성할 수 있다는 장점이 있다.

※ 원칙

• MVVM 패턴의 각 요소는 자신만의 명확한 책임을 가져야 한다
• 각 요소를 독립적으로 설계하여 테스트나 재사용이 가능하도록 한다

아래는 구성요소이다.

Model

데이터와 비즈니스 로직을 관리하는 부분.
데이터베이스, 네트워크 API 및 기타 데이터 소스와의 상호작용을 담당하며 data model, repository, service로 구분할 수 있다.

Data Model

데이터베이스에서 가져온 데이터를 앱 내부에서 처리할 수 있도록 객체화 한다.
예) 데이터 클래스

※ 원칙

• 데이터 구조만 담당해야 한다
• 재사용이 가능해야 한다. 즉, 특정 화면에 국한되지 않는 구조로 설계해야 한다.

Repository

데이터를 가져오거나 저장하는 로직을 관리하며, 데이터를 가져오거나 저장한 결과를 ViewModel로 전달한다.

※ 원칙

• 데이터 처리(CRUD) 작업만 수행한다
• 비즈니스 로직은 포함하지 않는다

Service

여러 Repository를 결합하여 View에서 사용할 데이터를 가공하고, 처리한 데이터를 ViewModel에 전달한다.

※ 원칙

• 비즈니스 로직을 포함한다
• 데이터를 가져오거나 저장하는 모든 작업은 Repository를 통해 수행한다

---

View

사용자 인터페이스(UI), 사용자와의 상호작용을 처리한다. ViewModel의 데이터를 관찰하여 UI를 업데이트 한다.

※ 원칙

• 화면 구현 또는 사용자 입력 처리만 수행해야 한다
• 데이터를 직접 조작하지 않고, 데이터 변경 요청만 Viewmodel에 전달한다

---

ViewModel

View에서 사용할 데이터를 보존하여 View 생명주기에 영향을 받지 않고 데이터를 유지할 수 있다.
View와 데이터 상태를 공유하기 위해 상태관리 라이브러리를 사용할 수 있다.
ex) Provider, GetX, Riverpod, Bloc ...

※ 원칙

• UI관련 이벤트는 View에서 처리하도록 한다
• 데이터를 직접 관리하지 않고 Service 또는 Repository를 통해서 수행한다
• 화면 전환과 같은 작업은 View에서만 처리한다
• Repository와 Service는 ViewModel에 직접 생성되지 않고, 의존성 주입을 통해 제공해야 한다

---

상호작용 흐름 예시

MVVM 패턴 설명과 함께 있었던 사진을 다시 보자

View ↔ ViewModel

• View는 사용자 입력 이벤트를 ViewModel로 전달한다
• View는 ViewModel의 데이터를 직접 다루지 않고, 데이터 변경 요청만 전달한다.
• ViewModel의 상태가 변경되면 View는 이를 관찰하여 UI를 갱신한다.

ViewModel ↔ Service

• ViewModel은 데이터를 요청하거나 처리하기 위해 Service를 호출한다
• Service는 요청받은 데이터를 처리한 후 ViewModel에 전달한다

Service ↔ Repository

• Service는 Repository를 호출하여 데이터베이스와 통신한다
• Repository는 통신 결과를 Service에 전달한다

Repository ↔ Data

• Repository는 데이터베이스와 직접 연결하여 데이터를 다룬다 (CRUD)

다음 게시글에서는 상태관리 라이브러리의 특징을 비교해보겠다