구글이 제안한 아키텍쳐 원칙들이 있다.
1. Separation of Concerns
걱정의 분리? (충돌과 같은 오류가 나지않게 분리한다는 느낌인듯)
일반적으로 모든 로직들을 액티비티나 프래그먼트에 넣는것은 큰 실수다. 액티비티와 프래그먼트에는 오로지 UI와 관련된 책임의 로직들만 가지고 있어야한다.
만약 그렇지 않은 로직들이 액티비티와 프래그먼트에 끼어있을 경우, 뷰의 생명주기(? : 아마 액티비티와 프래그먼트도)에 따라서 충돌을 일으킬수 있기때문이다. 뷰가 꺼진다고 해서 데이터가 초기화되거나 사라질수 있기 때문인가보다.
어쨌든 그리해서 UI클래스(액티비티, 프래그먼트)들은 네트워크 콜에 독립적이어야한다. 그리고 안드로이드 스튜디오의 라이프 사이클 문제를 피할수가 있게된다.
2. Drive UI from Model
모델에서 UI를 몰아내라?
... 1번과 같은 이유인듯하다.
---
그럼 왜 MVVM을 써야할까?
모든 패턴은 장단점을 가지고 있고 완벽한게 아니기 때문에, 필요에 따라 패턴을 골라 사용할 필요가있다. 그런데 구글은 MVVM 을 사용하길 추천한다.
아키텍쳐 구조
뷰는 = Activity / Fragment 클래스 그리고 레이아웃을 보여주는 XML이다.
그리고 뷰에서 데이터를 보여주기 위해서 뷰모델의 도움을 받아서 데이터 바인딩을 사용할 것이다. (안드로이드 스튜디오에서 제공하는 데이터바인딩이라는 라이브러리를 의미) 쨌든 뷰모델의 도움을 받는다는 의미이다. 다시말해 뷰(Activity클래스)는 데이터를 얻기위해 뷰모델에 의존하게된다.
뷰모델은 뷰의 데이터를 직접 업데이트를 안해줘도되기에. 뷰의 생애주기에 따른 문제를 피할수 있게된다. (뷰하고 엮이지 않게되서 뷰가 죽든말든 상관안함)
그리고 뷰모델은 데이터를 얻기 위해 레포지터리에 의존한다. 레포지터리는 로컬 데이터베이스일수도 있고 서버의 데이터일수도 있다.