[Android] MVVM 패턴

 

 

앱잼을 진행하면서 MVVM 패턴을 적용해보자는 우리팀 리드 선배의 말에 따라

1주일 동안 MVVM을 찍먹했다.

그리고 바로 코딩에 들어가니 제대로 이해 못하고 넘어간 부분이 많아 아쉬웠다.

그래서 앱잼이 끝난 지금, 다시 제대로 차근차근 공부해보려고 한다.

여기저기서 찾아보고 이해한 바를 작성하기 때문에 잘못된 정보가 있을수도 있다 :(

 

---

 

- MVVM 패턴을 적용하는 이유

기존에 사용하던 MVC패턴에 따라 Activity에 모든 코드를 넣으면 여러 문제가 발생하기 때문이다.

1️⃣ 앱 동작이 많을수록 Activity 자체가 무거워짐

2️⃣ View와 Model 간의 의존성의 높아져 코드가 복잡해짐

3️⃣ View의 UI Refresh를 위해 Model을 참조하므로 앱 규모가 커질수록 코드가 복잡해짐

즉, 규모가 커질수록 유지보수가 어려워진다.

 

그래서 의존성을 낮추고 동작을 분리하여 동작의 흐름을 더욱 체계적으로 만들어주고 유지보수를 편리하게 할 수 있도록 만들어 준 것이 MVVM 패턴이다!

 

 

- MVC 패턴 vs MVVM 패턴

 

🔥 MVC (Model, View, Controller)

MVC는 다음과 같은 형식으로 동작을 한다.

그림에서 볼 수 있듯, VIew와 Model간의 의존성이 굉장히 높아질 수 밖에 없고, controller(Activity)가 Model과 View 사이에서 하는 일이 많아지기 때문에 그만큼 동작이 무거워진다.

즉! 쉽게 접할 수 있을 만큼 구현하기 쉽다는 장점이 있지만, 규모가 커지게 되면 많은 코드가 Controller에서 담당하기 때문에 Application이 깨질 수 있는 문제점이 발생할 수 있는 구조이다.

 

각각의 요소에 대한 설명을 덧붙이자면

- Controller: Activiy 부분에서 View에게는 화면 업데이트, Model에서는 데이터 갱신을 알리며 View와 Model을 연결

- View: UI 역할

- Model: Model class로 비즈니스 로직에서의 알고리즘, 데이터 등의 기능 처리

 

 

이러한 문제점을 해결하기 위해 나온 것이 바로 MVVM 패턴이다.

 

 

 

🔥 MVVM (Model, VIew, ViewModel)

MVVM은 다음과 같은 형식으로 작동한다.

1. ViewModel이 VIew가 필요로하는 데이터를 쥐고 있고, VIew는 데이터를 관찰(Observing)한다.

즉, View가 DB에 직접 접근하는 것이 아니라 UI업데이트에만 집중하며, 관찰을 하고 있는 만큼 데이터 변화에 더욱 능동적으로 움직인다. (+ 직접 뷰를 바꿔주는 번거로움을 없애고 데이터와 불일치 할 확률이 적어진다.)

+) Model과 View사이, ViewModel과 View사이 의존성이 없다. (즉, View -> ViewModel -> Model 단방향 디펜던시를 갖는다) 따라서 여러개의 뷰가 하나의 뷰모델을 사용할 수 있고, 각각 독립적이기에 모듈화하여 개발할 수 있다.

2. 생명주기로부터 안전하여 메모리 릭을 방지할 수 있다.

뷰모델을 통해 데이터를 참조하기 때문에 액티비티, 프래그먼트의 생명주기를 따르지 않는다. (화면전환과 같이 액티비티가 파괴된 후 재구성되어도 뷰모델이 데이터를 홀드하고 있기 때문에 영향을 받지 않는다.)

3. 뷰가 활성화 되어있을 때만 작동하기에 불필요한 메모리 사용을 줄일 수 있다. 

 

📌 즉! MVVM은 View가 ViewModel의 Data를 관찰하고 있으므로 UI 업데이트가 간편하고,

기능별 모듈화가 잘 되어 있어 유지 보수에 용의하다. (의존성 최소화!)

+) entity와 usecase를 포함한 model계층, repository 혹은 presenter 역할을 맡는 중간 계층인 view model, 가장 바깥의 ui를 담당하는 view 계층을 분리해 의존성 규칙에 따라 관심사를 분리한 형태의 디자인 패턴 말함. -> 비즈니스 로직과 프레젠테이션 로직을 UI로 부터 분리!

 

❗ 각각의 요소에 대한 정리 ❗

✅ View:

- Activity 역할을 담당하고 UI를 갱신하는 역할에만 충실히 한다.

- 또한 뷰모델을 관찰 (Ovserve)하므로 데이터의 변화를 알아차리고 자동으로 화면을 갱신. 

 

✅ ViewModel

- 비즈니스 로직을 담당. View와 관련된 비즈니스 로직은 이곳에 들어가게 되며 데이터를 잘 가공하여 View에서 뿌리기 쉬운 Model로 바꾸는 역할을 함. (Model에게 데이터 갱신 처리를 요청하고 잘 정리된 데이터를 참조)

- View를 나타내 주기 위한 Model이잦 View를 나타나내기 위한 데이터 처리를 하는 부분

- View가 관찰(Observe)하고 있기에 View가 갱신할 수 있도록 Observable(RxJava, Listener, LiveData)로 알리거나 DataBinding을 통해 알려야 함.

- View의 Context를 지니고 있으면 안 됨. View와 Lifecycle이 다르기에 메모리릭 발생할 수 있음

 

✅ Model

- 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분.

- DataModel이라고도 하며 DB, Network, SharedPreference 등 다양한 데이터 소스로부터 필요한 데이터를 준비함.

 

 

 

 

이렇게하면 MVC와 비교하여 MVVM을 써야하는 이유를 익혔으니, 

MVVM의 구성요소를 Android Jetpack의 구성요소 AAC와 구현한다고 해보자.

* Android Jetpack이란?

Jetpack은 개발자가 고품질 앱을 손쉽게 개발할 수 있게 돕는 라이브러리, 도구, 가이드 모음입니다. 이 구성요소를 통해 권장사항을 따르고, 상용구 코드 작성 작업에서 벗어나며, 복잡한 작업을 간소화하여 중요한 코드에만 집중할 수 있습니다.  Jetpack은 플랫폼 API와 별도로 제공되는 androidx.* 패키지 라이브러리로 구성됩니다. 즉, 이전 버전과 호환되며 Android 플랫폼보다 더 자주 업데이트되므로 개발자는 항상 가장 뛰어난 최신 버전의 Jetpack 구성요소에 액세스할 수 있습니다.

 

*AAC란?

AAC(Android Architecture Components)는 테스트와 유지보수가 쉬운 앱을 디자인할 수 있도록 돕는 라이브러리입니다.

 

 

📌Activity/Fragment: UI를 담당하는 액티비티, 프래그먼트를 의미. 화면에 무엇을 그릴지 결정하고 사용자와 상호작용. 보통 데이터의 변화를 감지하기 위한 Observer를 가지고 있다.

📌VIewModel: 화면 변화 시에도 변하지 않는 (사라지지 않는) 데이터를 가지고 있다 (액티비티나 프래그먼트의 생명 주기에서 자유로울 수 없지만, 뷰모델은 뷰와 분리되어 있기 때문에 액티비티가 Destory 되었다가 Create되어도 종료되지 않고 데이터를 여전히 유지하고 있다.)

📌Live Data: View가 ViewModel을 관찰할 때, 그 관찰 대상이 되는 데이터 홀더 클래스이다. 뷰에서 뷰모델의 LIve Data를 관찰하게 되면 데이터가 변경될 때 내부적으로 자동으로 알려주게 된다. Live Data는 Activity 및 Fragment의 Life Cycle을 인지하지 못하므로, 화면이 활성화 되어 있을 때만 동작하여 Memory Leak을 줄여준다.

📌Repository: ViewModel 과 데이터를 주고받기 위해, 데이터 API를 포함하는 클래스이다. 사용자 동작에 따라 필요한 데이터나 외부 백엔드 서버 등에서 데이터를 가져오게 된다. Repository의 존재 덕분에 ViewModel이 데이터를 관리할 필요가 없게 된다. 

📌RoomDataBase: Room은 SQLite를 사용함에 있어서 별도의 Query문 작성없이 간단하게 Insert, Delete 등의 동작을 할 수 있게끔 도와주는 ORM 라이브러리이다.