MVVM + Repository에 대하여 공부하고, 제 생각을 공유 및 설명드려보려고 합니다.
먼저 mvvm 의 관한 설명은
https://developer.android.com/jetpack/guide?hl=ko#recommended-app-arch
안드로이드 공식 문서에 잘 나와있습니다.
위의 내용과 더불어 repository 패턴에 추가로 얘기를 해보면 먼저 아래사진을 보겠습니다.
위의 사진이 설명을 잘 해주고있는데, Activity 혹은 Fragment는 ViewModel에 의존을 합니다.
그럼 ViewModel은 Repository에 의존을 하고, Repository는 room 혹은 retrofit에 의존을 하고있습니다.
위의 내용을 반대로생각을 헤보면 ViewModel은 Activity / Fragment 를 알 수 없게되는데, 이 말은
ViewModel은 UI에 간섭을 할 수 없게되고, UI 관리는 Activity / Fragment 만 할 수 있게 됩니다.
공식문서에 나와 있듯이, 관심사 분리가 되는 것입니다.
그렇다면, 장점은 무엇일까요?
예를들어, room 혹은 retorfit을 통해 데이터를 받아야 하는 상황이라면, ViewModel 에서 바로(직접) data에 접근하여 가져오는 것이 아니라, Repository가 데이터에 접근하여 가져온 데이터를 ViewModel에게 전달해주게 됩니다.
이 말은 우리가 필요한 Data가 어디서왔는지에 상관없이, UI에 데이터를 그리게 될때, 동일한 인터페이스로 데이터에 접근할 수 있게됩니다.
이 말을 코드로 간단히 설명을 하자면, retrofit을 이용해 뉴스 정보를 가져와 recyclerview에 출력을 한다고 생각해봅시다.
Activity / Fragment 에서는 Viewmodel에 있는 함수를 호출합니다.
-> viewmodel.getNews()
그럼 ViewModel에 있는 getNews() 함수는 Repository에 있는 함수를 호출합니다.
-> repository.getNews()
Repository에 있는 getNews() 함수는 Retrofit 서버 통신 함수를 호출합니다.
-> retrofit.getNews()
즉, 위와같이 관심사 분리가 이루어지고, Data Layer가 캡슐화 되고
ViewModel이 있는 Presentation Layer 에서는Data Layer를 직접 호출하지 않고 Repository를 통해서만 접근하게 됩니다.
만약 데이터를 preference를 사용한다고 가정했을때, 이것을 바로 ViewModel에서 사용을 하게된다면, 뷰모델은 preference에 의존성을 가지게 되고, 나중에 preference를 수정하게 될 일이 생기면, ViewModel 또한 수정을 해야하는 일이 생깁니다.
하지만, 이것을 repository 단계로 나누었다면, repository 구현부만 수정을하면 뷰모델은 수정 할 필요가 없겠죠.
이처럼 코드 수정 혹은 마이그레이션에도 편리해집니다.
마지막으로, repository를 비유를 해서 설명을 한다면 우리가(Activity / Fragment)
편의점(ViewModel)에서 과자를 살때 이 과자가 어느 공장(평택, 이천, 남양주)에서 왔는지 알 필요가 있을까요?
그저 과자를 사서 맛있게 먹으면 되는것이죠.
하지만 우리가 그 과자를 사기 위해서는 평택이든 남양주든 어느 특정 한 공장에서 만든 그 과자를 편의점으로 유통해야 합니다.
여기서 우리가 과자를 살 때, 어느 공장인지 모르는(알 필요가 없는, 유통) 역할을 하는 것이 repository 입니다.
만일 이 repository 와 ViewModel이 분리가 되어있지 않다면, 우리는 과자를 먹기 위해 그 공장까지 가야합니다.
비유가 좋은지는? 모르겠지만, 이해를 도우면 좋겠습니다.
