MVVM 적용기(1)

 

내가 기존 회사에서 처음으로 시도해봤던 아키텍처 패턴은 MVP 패턴으로,

데이터 소스에 대한 접근은 Model이 담당하고,

사용자에게 데이터를 보여주는 부분(Activity,Fragment)는 View가 담당하며,

두 사이를 Presenter가 매개하는 형식의 패턴이라고 할 수 있다.

위 패턴을 직접 업무에서 적용하려고 했을 때 발생한 문제는 다음과 같았다.

1. 일반적으로 View와 Presenter를 정의한 인터페이스인 Contract 등을 따로 정의해야 했고, 매번 두 아키텍처 컴포넌트를 변경해야 할 일이 생길 때마다 해당 인터페이스를 무조건적으로 변경해야 하므로 일을 두 번하게 되었다.
2. View에는 데이터를 표시하는 일만 담당시키고, 복잡한 로직은 Presenter에게 위임시켜야 이상적인 MVP 패턴이라고 할 수 있으나, 로직을 분리시키는 과정에서 안드로이드 프레임워크에 의존적인 로직을 Presenter로 분리시키기가 어려워, 사실상 Presenter가 View와 책임 분담이 제대로 되지 않았다.
3. Presenter가 둘 사이에서 많은 일들을 해야하기 때문에, 많은 책임을 안게 되어 클래스가 지나치게 비대해져갔다.

특히나 많은 어려움을 느낀 것이 View와 Presenter 로직의 분리였다.

특정 로직은 액티비티의 Context가 필요한 경우가 많거나 Intent를 이용해야 해서, 사실상 특정한 같은 기능을 실행하지만 View와 Presenter가 그 기능을 구현하기 위해 로직을 분담해야만 했다.

이후 눈길이 갔던 것이 MVVM이었다.

내게는 생소했지만 최근의 구직 시장에서도 MVVM을 구현할 줄 아는 인재의 수요가 많은 것 같았고,

무엇보다도 구글에서도 공식적으로 MVVM을 구현하기 위한 AAC와 Jetpack 컴포넌트들을 내놓으면서, 진입장벽도 많이 낮아졌다는 느낌이다.

MVVM 패턴의 흐름을 표현하고 있는 그림이다.

위 그림으로 표현된 MVVM 패턴을 간략하게 설명해보면 다음과 같다.

1. View는 MVP 패턴에서와 마찬가지로 데이터를 불러와 사용자에게 표시해주는 역할을 하고, 사용자로부터 동작이 들어오면 ViewModel에 데이터 변경을 요청한다.
2. ViewModel은 View에서 들어온 요청을 받아 데이터를 저장하고 있는 Model에 다시 요청한다
3. 요청을 받은 Model은 데이터를 가공하여 ViewModel로 다시 전달하고,
4. ViewModel은 데이터를 받아 저장한다.
5. View는 ViewModel의 데이터를 관찰하는 Observer를 가지고 있어, 변경된 데이터가 있으면 바로 사용자에게 보여준다.

View는 ViewModel 객체로 가져 데이터를 요청하고,

ViewModel은 데이터를 요청하고 저장하기만 하면

그걸 바라보고 있는 View는 그대로 데이터를 뿌려주기만 하면 된다고 보면 되겠다.

이것을 구현하기 위해 구글은 AAC(Android Architecture Component)라는 것을 제공한다.

AAC는 각 안드로이드 컴포넌트의 생명주기를 고려하여 만들어졌다.

위에서 보이는 Repository가 Model의 역할을 한다고 보면 되겠다.

Model이 데이터에 접근하여 제공하는 역할을 하는데,

일반적으로 DB는 외부 서버에 접근하는 경우가 많으므로

내부 데이터는 Room에 저장하고, 외부 데이터는 Retrofit 등의 API 통신 프레임워크등을 이용한다.

그리고 이 두 접근을 Repository가 책임 진다고 보면 되겠다.

다음 편에는 이 구조를 실제 코드로 구현하는 과정에 대해 포스팅해보도록 하겠다.

필자는 MVVM을 처음 적용해보므로,

과정에 부족함이 있다고 하더라도 양해 바란다.

참조

https://velog.io/@hwi_chance/Android-안드로이드-AAC

https://beomy.tistory.com/43