MVC
- 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 패턴은 구현하기 쉬운 장점이 있는 반면, 기능 추가 및 변경에 있어 유지보수가 어렵다.
-
MVVM 은 기존 MVC 에서 Controller 에게 막중한 역할을 부여하기보다, 이 동작 자체를 분리하여 동작의 흐름을 더욱 체계적으로 만들어주고 유지보수를 편리하게 할 수 있도록 해주는 디자인 패턴이다.
-
MVVM(Model-View-ViewModel)
-
기존 MVC에서 Controller 에게 막중한 역할을 부여하기보다, 이 동작 자체를 분리하여
-
동작의 흐름을 더욱 체계적으로 만들어주고 유지보수를 편리하게 할 수 있도록 해주는 디자인 패턴이다.
Model
-
Model은 사용하려는 데이터를 가지고 있는 비시각적 클래스입니다.
-
예를 들어 DTO(Data Transfer Object), POJO(Plain Old Java Object)나 엔티티 개체 등이 있습니다.
-
일반적으로 데이터를 액세스하거나 캐싱이 필요한 서비스 또는 리포지토리와 함께 사용됩니다.
View
-
View는 화면에 보이는 레이아웃 구조를 담당합니다.
-
UI와 관련된 로직을 수행할 수 있습니다.
ViewModel
-
ViewModel은 View에 연결된 데이터와 명령을 구현하고 변경 알림 이벤트를 통해 상태의 변경을 View에 알립니다.
-
상태 변경 알림을 받은 View는 변경을 적용할지 말지를 결정하게 됩니다.
-
여기서 말하는 ViewModel과 AAC(Android Architecture Component)의 ViewModel은 다릅니다.
-
AAC에서의 ViewModel은 화면 회전같은 변화에서 View에 사용되는 데이터를 유지시키기 위한, Lifecycle을 알고있는 클래스입니다.
-
안드로이드 개발을 하면서 MVVM 패턴을 사용하려고 한다면, 반드시 AAC의 ViewModel을 사용하지 않아도 구현은 가능합니다.
View
-
Activity / Fragment 가 View 역할을 함
-
사용자의 Action 을 받음 (텍스트 입력, 버튼 터치 등)
-
ViewModel의 데이터를 관찰하여 UI 갱신
ViewModel
-
View가 요청한 데이터를 Model 로 요청함
-
Model로부터 요청한 데이터를 받음
Model
-
ViewModel이 요청한 데이터를 반환함
-
Room, Realm과 같은 DB 사용이나 Retrofit을 통한 백엔드 API 호출 (네트워킹) 이 보편적
-
결국 View 가 필요로 하는 데이터는 ViewModel 이 쥐고 있고, View 는 그것을 필요로 하기 때문에 ViewModel 이 쥐고 있는 데이터를 관찰 (Observing) 한다.
-
때문에 MVC 패턴과 다르게, View 가 DB 에 직접 접근하는 것이 아닌 UI 업데이트에만 집중한다.
-
또한 관찰하고 있는 만큼 데이터 변화에 더욱 능동적으로 움직이게 된다.
-
따라서 MVVM 패턴은 다음과 같은 장점을 가진다.
-
MVVM 장점
-
View가 ViewModel의 Data를 관찰하고 있으므로 UI 업데이트가 간편
-
ViewModel이 데이터를 홀드하고 있으므로 Memory Leak 발생 가능성 배제(View가 직접 Model에 접근하지 않아 Activity / Fragment 라이프 사이클에 의존하지 않기 때문)
-
기능별 모듈화가 잘 되어 유지 보수에 용이 (e.g. ViewModel 재사용 및 DB 교체 등의 작업이 편리함)
-
이러한 장점을 가지고 있는 MVVM 패턴은 잘만 사용한다면 훌륭한 앱을 만들 수 있다.
-
그렇지만 그만큼 구조가 복잡하다는 단점이 크게 다가온다. 진입장벽이 상당하다.
-
그래도 MVVM 패턴을 간편하게 적용해볼 수 있게끔 구글에서 AAC라는 것을 제공한다.
AAC(Android Architecture Component)
ViewModel
- 화면 변화 시에도 변하지 않는 (사라지지 않는) 데이터를 가지고 있다.
Live Data
-
View가 ViewModel 을 관찰할 때, 그 관찰 대상이 되는 데이터 홀더 클래스이다.
-
Live Data는 Activity 및 Fragment의 Life Cycle을 인지하지 못하므로, 화면이 활성화 되어 있을 때만 동작하여 메모리 릭을 줄여준다.
Repository
-
ViewModel과 데이터를 주고받기 위해, 데이터 API를 포함하는 클래스다.
-
사용자 동작에 따라 필요한 데이터나 외부 백엔드 서버 등에서 데이터를 가져오게 된다.
-
Repository의 존재 덕분에 ViewModel이 데이터를 관리할 필요가 없게 된다.
RoomDatabase
- Room은 SQLite를 사용함에 있어 별도의 Query문 작성없이 간편하게 Insert, Delete 등의 동작을 할 수 있게끔 도와주는 ORM 라이브러리이다. (공식 문서에 따르면 Realm 같은 친구를 사용해도 상관이 없다고 한다.)
