👉 MVC vs MVVM
Android 앱 개발을 하다보면, Activity 클래스에 모든 동작 코드를 다 집어 넣는 경우가 많았다.
그러다 보니 앱이 동작하는 데에는 큰 문제가 없었지만 체계적인 구조 없이 코드를 작성하여 추후에 유지 보수하기가 굉장히 까다롭다.
여러 프로젝트를 진행하다 보면 이렇게 코드를 작성했을 때, 기능을 바꿔야하거나 추가하여야 하는 경우 어떤 부분을 수정해야 할지 막막했던 경험이 있다.
이러한 경험을 토대로 요즘 대세인 MVVM 디자인 패턴을 공부하고, 적용해봐야겠다는 생각이 들었다.
기존에 많이 쓰였던 단순한 형태의 MVC 패턴에 따라 Activity에 모든 코드를 다 집어넣으면 이러한 단점들이 발생하였다.
- 앱 기능이 많아질 수록 Activity 자체가 무거워진다.
- View와 Model 간의 의존성이 높아지고 코드가 복잡해진다.(일명 스파게티 코드)
- View와 UI Refresh를 위해 Model을 참조하므로 앱의 규모가 커질수록 코드가 더 복잡해지게 된다.
이런 단점들을 보면, MVC 패턴은 규모가 커질수록 유지보수하기가 점점 어려워진다는 것을 알 수 있다.
MVC 패턴의 동작은 아래와 같다.
- Controller가 사용자의 요청을 받아들인다.
- Controller가 사용자의 동작에 따른 Model 없데이트를 요청한다.
- Controller가 Model을 나타낼 View를 선택한다.
- View는 Model을 참조하여 UI를 업데이트한다.
이렇게 되다 보니 View와 Model 간의 의존성이 높아질 수 밖에 없다.
또 Controller(Activity)가 Model과 View 사이에서 바쁘게 움직이고 있다.
혼자서 요청을 보내야 하기 때문에 Controller는 당연히 동작이 무거워진다.
따라서 코드 유지보수를 하다가 잘못하면 UI 랜더링 속도가 느려져 프레임 스킵 현상 및 메모리 누수 (Memory Leak)의 위험이 생길지도 모른다.
MVC 패턴은 구현하기에는 쉬운 장점이 있지만, 기능 추가 및 수정에 있어서 유지보수하기가 어렵다.
이러한 MVC 패턴의 단점을 보완하기 위해 등장한 디자인 패턴이 바로 MVVM 패턴이다.
MVVM 패턴은 기존 MVC에서 Controller가 혼자 일하기 보다, 이 동작 자체를 분리하여 동작의 흐름을 더욱 더 체계적으로 만들어주고 유지보수를 편리하게 할 수 있도록 해주는 디자인 패턴이다.
MVVM 패턴은 Model, View, ViewModel로 이루어져 아래와 같은 동작을 한다.
View
- Activity 나 Fragment가 View 역할을 한다.
- 사용자의 요청을 받는다.
- ViewModel의 데이터를 관찰하여 UI를 갱신한다.
ViewModel
- View가 요청한 데이터를 Model로 요청한다.
- Model로 부터 요청한 데이터를 받는다.
Model
- ViewModel이 요청한 데이터를 반환한다.
- Room, Realm과 같은 DB 사용이나 Retrofit을 통한 백엔드 API 호출 (네트워킹)이 보편적이다.
결국 View가 필요로 하는 데이터는 ViewModel이 쥐고 있고,
View는 그것을 필요로 하기 때문에 ViewModel이 쥐고 있는 데이터를 관찰한다.
그렇기에 MVC 패턴과 다르게, View가 DB에 직접 접근하는 것이 아닌 UI 업데이트에만 집중하고 관찰하고 있는 만큼 데이터 변화에 더욱 능동적으로 움직이게 된다.
MVVM 패턴의 장점은 다음과 같다.
- View가 ViewModel의 데이터를 관찰하고 있으므로 UI 업데이트가 간편하다.
- ViewModel이 데이터를 홀드하고 있으므로 Memory Leak 발생 가능성을 배제할 수 있다.(View가 직접 Model에 접근하지 않아서 Activity나 Fragment 생명주기에 의존하지 않기 때문이다.)
- 기능별 모듈화가 잘 되어 유지 보수에 용이하다.
이러한 장점을 잘 활용하여 MVVM 패턴을 가지고 앱 개발을 한다면 좋은 앱을 만들 수 있을 것 같다. 하지만 그만큼 구조가 복잡하여 진입장벽이 높다고 한다.
그래서 인지 MVVM 패턴을 간편하게 적용해볼 수 있게끔 구글에서 AAC라는 것을 제공한다.
AAC (Android Architecture Component)
AAC란 구글에서 발표한 안드로이드 개발 가이드이다. 구글은 많은 개발자들에게 앱을 잘 만들게 하기 위해 이런 가이드라인을 제시하였다. 구조는 아래와 같다.
ViewModel
화면 변화 시에도 변하지 않는 (사라지지 않는) 데이터를 가지고 있다.
Live Data
View가 ViewModel을 관찰할 때, 그 관찰 대상이 되는 데이터 홀더 클래스이다. Live Data는 Acivity 나 Fragment의 생명주기를 인지하지 못하므로, 화면이 활성화 되어 있을 때만 동작하여 메모리 누수를 줄여준다.
Repository
ViewModel과 데이터를 주고받기 위해, 데이터 API를 포함하는 클래스이다. 사용자 동작에 따라 필요한 데이터나 외부 백엔드 서버 등에서 데이터를 가져오게 된다. Repository의 존재 덕분에 ViewModel이 데이터를 관리할 필요가 없게 된다.
RoomDatabase
Room은 SQLite를 사용함에 있어 별도의 Query문 작성없이 간편하게 Insert, Delete 등의 동작을 할 수 있게끔 도와주는 ORM 라이브러리이다.
