MVVM 알아보기

 

안드로이드를 접한지는 1년이 되어간다. 그 중에 정말 집중해서 한 기간은 6개월 정도다. 난 구현에만 신경썼기 때문에 의존성을 분리하는 게 좋다는 아주 기초적인 지식만을 갖고있었다. 이번에 새 프로젝트에 참여하게 됐는데 민폐를 끼치지 않기위해 공부를 해야한다. 첫번째로 MVVM이다.

일반 아키텍처 원칙

패턴을 들어가기 전에 안드로이드 공식 문서에서 지정한 아키텍처 원칙을 학습하겠다. 번역 오류를 피하기 위해 영문과 같이 봤다.

• 관심사분리
• 데이터 모델에서 UI 도출하기
• 단일 소스 저장소
• 단방향 데이터 흐름

이렇게 네 가지가 주어졌다.

관심사 분리 Separation of concerns

가장 중요하고 제일 우선시 되어야 할 원칙이다. Activity나 Fragment는 UI기반 클래스다. 이 경우 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야한다. 담당하는 부분을 분리한다는 개념으로 각 클래스끼리 의존성을 낮추는 방법이다. Activity나 Fragment는 단지 Android OS와 앱을 연결해주는 중간다리다. OS가 사용자의 요청이 들어오면 언제든지 메모리에서 날릴 수 있기 때문에 이런 관심사를 분리하는 작업은 필수다.

데이터 모델에서 UI 도출하기 Drive UI from data models

데이터 모델은 앱의 데이터를 의미한다. 앱의 UI요소 및 기타 구성요소와 독립되어있는 모델이다(수명주기의 분리). 앱의 데이터이므로 앱의 프로세스를 os가 제거하면 당연히 데이터 모델도 제거된다.

가급적이면 지속모델(persistent models)을 권장하는데, 첫번째로 OS가 리소스를 확보하기 위해서 메모리에서 앱을 제거해도 사용자 데이터가 삭제되지않는다. 이것은 방금 말한 프로세스가 제거되면서 데이터 모델이 제거된다는 것과 조금 다른데, 사용 중이던 임시 데이터 모델을 제거하는 것이고 이걸 별도의 저장소에 넣으면 앱을 제거해도 사용자 데이터가 남아있게 된다. 두번째로 네트워크 연결 유무에 상관 없이 앱이 동작한다는 것이다. 데이터가 네트워크에 의존적이면 이렇게 동작하지 않는다.

단일 소스 저장소 SSOT(Single source of truth)

새 데이터가 정의될 때 이 데이터를 SSOT에 할당해서 SSOT만 수정하거나 변경할 수 있게 해야한다. 이걸 위해 immutable type으로 사용해서 데이터를 읽게 해야한다. 단일 소스를 이용해서 데이터에 접근하기 때문에 잘못된 데이터 사용을 방지하고 데이터 변경사항 추척을 쉽게 만들어 버그 발견에 용이하다.. 또 특정 유형 데이터의 모든 변경사항을 한군데로 모은다.

여기서 말하는 소스에 해당하는 것으로는 DB, ViewModel, UI 등이 있다.

단방향 데이터 흐름 UDF(Unidirectional Data Flow)

문서에서 심심찮게 볼 수 있는 용어다. SSOT가 UDF패턴과 함께 사용되기도 한다. UDF에서 상태(state)는 단방향으로만 흐른다. 데이터를 수정하는 흐름인 이벤트(event)는 상태와 반대방향으로 흐른다. 보통 상태나 데이터는 상위 범위에서 하위 범위로 흐른다. 이벤트는 하위 범위에서 트리거돼서 상호작용하는 데이터의 SSOT에 도달한다.

App Data -> UI, UI(터치와 같은 사용자 이벤트) -> SSOT에서 데이터 수정

UDF를 사용하면 더 적은 오류와 데이터 일관성을 보장한다. 일관성은 디버그를 쉽게 만든다.

MVVM패턴

MVVM은 Model - View - ViewModel의 약자다.

뷰는 UI를 생각하면 되고, Model은 비즈니스 로직(백엔드 로직)을 생각하면 된다. 비즈니스 로직은 앱의 데이터 생성, 저장, 변경 방식 등을 결정하는 규칙이다. 이 뷰와 모델을 분리시키면 뷰를 어느 특정 모델에 종속시키지 않을 수 있다. 분리시키기 전에는 특정 모델에는 특정 뷰가 종속되어있는 형태다. 뷰 모델은 모델의 데이터 객체를 뷰로 변환하는 값 변환기다. 그래서 뷰 모델은 뷰보다 모델에 가깝고 뷰의 디스플레이 로직 이외의 대부분 작업을 처리한다. MVVM은 모델 - 뷰 - 바인더라고도 하는데 이건 구성요소를 좀 더 살피면서 알아보겠다.

모델 Model

모델은 실제 상태/데이터 내용을 표현하는 데이터 접근 계층을 참조한다. 데이터에 가장 가까운 레이어다.

뷰 View

뷰는 UI에 해당한다. 사용자가 보는 모든 것을 지칭하며, 모델을 보여서 표현하고 뷰와 사용자 간의 이벤트를 수신해서 뷰-뷰모델 사이의 데이터 바인딩을 통해 뷰모델로 이벤트를 전달한다.

뷰 모델 ViewModel

MVVM패턴의 핵심이다. MVC에서 컨트롤러, MVP에서 프리젠터를 대신하는 역할이며 모델에 있는 데이터의 상태를 뷰로 변환하는 값 변환기이다. 프리젠터와 뷰모델의 차이점은 뷰에 대한 참조 유무인데 뷰모델은 뷰를 참조하지않는다. 간접연결인 참조가 아니라, 직접 바인딩을 해서 업데이트를 주고받는다. 따라서 바인더가 필요하다.

바인더/연결자 Binder

바인더는 뷰모델에 있는 뷰와 연결된 속성과 뷰 사이의 통신을 담당한다. 바인더가 있어야 데이터바인딩을 통해 MVVM패턴을 구현할 수 있다.

작동 방식

1. View에서 유저와 이벤트 발생
2. ViewModel에 있는 속성과 데이터바인딩을 통해 이벤트 전달
3. ViewModel이 Model에게 데이터 요청
4. Model이 ViewModel에게 데이터 응답
5. ViewModel이 받은 데이터를 가공(View에 쓸 수 있게)
6. View 업데이트

데이터 바인딩을 통해서 MVP에 있던 View에 대한 의존성을 없앴다고 위에서 말했는데, 뷰모델을 데이터 바인딩을 이용해 하나의 한 가지 뷰 모델에 여러개의 뷰를 붙일 수 있기 때문이다. 1대1 관계였던 MVP의 View-Presenter에서 ViewModel이 1인 1:N 관계로 발전했다.

즉 MVVM은 MVC가 갖는 장점인 기능요소 개발의 분리와 MVP의 단점을 없애줄 데이터바인딩을 합쳤다고 볼 수 있다. 문제는 각 요소가 독립적이다 보니 이걸 분리하는데 드는 비용이 더 커질 수 있다는 점과 그에 따라 ViewModel의 설계가 어려워진다는 것이다.

이제 MVVM패턴의 정의를 학습했으니 안드로이드 공식문서에서 말하는 권장 앱 아키텍처를 보겠다.

권장 앱 아키텍처

일반 아키텍처 원칙에서 얘기하는 레이어는 UI레이어와 데이터 레이어다. 여기에 두 레이어 간 상호작용을 간소화하고 재사용하기 위한, 즉 의존성을 낮추기 위한 도메인 레이어를 추가 할 수 있다. 화살표는 종속 관계다. 도메인 레이어가 데이터 레이어에 종속된다는 의미다.

UI 레이어 (프레젠테이션 레이어)

UI는 UI elements와 State holders로 구성된다.

UI elements는 화면에 데이터를 보여주는 UI요소로 MVVM의 View와 비슷하고, State holders는 데이터를 보유하고 UI에 뿌릴 로직을 처리한다.

데이터 레이어

데이터 레이어에는 비즈니스 로직이 있다. 시스템과 앱 사이에서 데이터 작업을 할 데이터 소스와 그 데이터 소스를 포함할 리포지토리(저장소)로 구성된다. 처리하는 데이터의 유형별로 리포지토리 클래스를 만들어야한다.

데이터 레이어는 SSOT, UDF를 준수해야한다.

도메인 레이어

도메인 레이어는 복잡한 비즈니스 로직이나 여러 ViewModel에서 재사용되는 간단한 비즈니스 로직의 캡슐화를 담당한다. MVVM패턴 조금 수월하게 구현할 수 있게 해주는 레이어이다. 도메인 레이어를 사용하면

코드 중복, 가독성 개선, 테스트 용이성, 책임분할(대형 클래스 방지)

가 가능하다.

일반적으로 데이터 레이어의 리포지토리 클래스에 종속되어 코루틴을 사용해 UI레이어와 통신한다. 도메인레이어의 클래스는 UseCase라고 이름이 붙는데 각 클래스당 하나의 기능을 담당해야한다. 또한 도메인 레이어의 UseCase는 main-safe해야하므로 메인스레드에서 호출되어야 한다. 만약 UseCase 클래스가 오랫동안 blocking operation을 하고 있다면(대용량 데이터 수신과 같은), 적절한 스레드로 로직을 옮기게 된다.

옮기기 전에 이미 데이터 레이어에서 복잡한 연산작업을 담당하기 때문에, 대용량 목록을 대상으로 결과를 캐싱하여 앱 여러 뷰에서 재사용이 필요한 경우에는 리소스 집약적인 작업이기 때문에 데이터 레이어에 배치된다.

/**
 * This use case fetches the latest news and the associated author.
 */
class GetLatestNewsWithAuthorsUseCase(
  private val newsRepository: NewsRepository,
  private val authorsRepository: AuthorsRepository,
  private val defaultDispatcher: CoroutineDispatcher = Dispatchers.Default
) {
    suspend operator fun invoke(): List<ArticleWithAuthor> =
        withContext(defaultDispatcher) {
            val news = newsRepository.fetchLatestNews()
            val result: MutableList<ArticleWithAuthor> = mutableListOf()
            // This is not parallelized, the use case is linearly slow.
            for (article in news) {
                // The repository exposes suspend functions
                val author = authorsRepository.getAuthor(article.authorId)
                result.add(ArticleWithAuthor(article, author))
            }
            result
        }
}

예제 코드인데 데이터 레이어에 존재할 Repository 객체들을 받아서 코루틴인 withContext로 처리한다. Dispatcher를 Default로 줘서 백그라운드 스레드로 옮겨 withContext로 메인 스레드와는 독립적으로 작동한다.

withContext

withContext는 비동기작업을 동기적으로 작동하게 하는 문법이다. withContext의 파라미터에 사용할 디스패처를 넣고(여기서는 Default다), 해당 스레드에서 작업이 끝나기 전까지 메인 스레드에서 수행되던 코루틴을 일시중단한다. 또 마지막 줄을 반환하기 때문에 return이 따로 없어도 위 코드에서 result가 invoke()의 return 값인 List<ArticleWithAuthor>에 들어간다. 즉 결과값 수신이 필요한 경우 withContext를 이용해 수신을 확실히 하고 갈 수 있다는 장점이 있다.

---

 

참조:

https://developer.android.com/topic/architecture?authuser=1&hl=ko#common-principles

모델-뷰-뷰모델 - 위키백과, 우리 모두의 백과사전

[디자인패턴] MVC, MVP, MVVM 비교

https://developer.android.com/jetpack/guide/domain-layer?authuser=1&hl=ko

https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/with-context.html

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요! 로그인 안해도 됩니다 ^_^