MVVM : 구글의 뷰모델은 MVVM의 뷰모델이 아니다.
AAC 뷰모델과 그냥 뷰모델의 차이가 뭔지 알자.
그럼 왜써야 하냐?? 확고한 생각을 가지자
MVC, MVP, MVVM
MVC → 서버사이드 개념이다. 유저와 소통하는 곳이 CONTROLLER.
안드로이는 시작도, 입력도, 유저의 액션도 모두 VIEW에서 시작한다.
클라이언트 사이드의 역할은?
화면제공, 이벤트 처리, 비즈니스 로직처리, 업데이트 등등의 역할을 한다.
아키텍처를 분리하지 않으면 모든 역할을 액티비티가 처리한다.
그러면 뷰와 컨트롤러의 분리가 제대로 이루어지지 않는다.
MVP는 뷰에서 모든것이 시작된다.
MVC의 역할을 따라 변형시킨 모델이다.
PRESENTER안에서 모델 실행
뷰에 들어오는 모든 이벤트는 프레젠터에서 처리되도록 해야한다.
MVVM → MVP의 개선.
뷰에서 이벤트 발생, 뷰모델로 이벤트 전달
→ 뷰모델에서 모델에게 데이터 요청
모델로부터 응답받은 데이터를 뷰모델이 저장
뷰에서 이를 관찰하고 뷰에 적용
뷰모델 : 뷰와 모델 사이에서 데이터 관리하고 바인딩 해주는 역할.
뷰는 뷰모델이 관리하는 데이터를 관찰하고 변경이 일어나면 화면을 업데이트한다.
구현과정에서 커맨드 패턴과 데이터바인딩으로 뷰모델과 뷰의 의존성을 분리할 수 있다.
커맨드 패턴으로 뷰의 요청을 뷰모델에서 캡슐화할 수 있다.
공식문서에서 하라고 하는게 뭘까
앱의 구조는 복잡하다. 진입점이 하나가 아니다. 여러앱과 상호작용 한다. 사용자 중심으로 다양한 워크플로 작업에 맞게 조정될 수 있어야 한다.
안드로이드의 환경은 리소스가 제한되어 새로운 앱 공간을 확보하기 위해 일부 앱을 종료하기도 한다.
그래서 앱 구성요소에 앱의 데이터나 상태를 저장하면 안되고, 앱 구성요소 끼리도 종속되서도 안된다. 앱의 데이터나 상태는 내 예측대로 돌아가지 않는 경우도 발생한다.
아키텍쳐를 사용할때 다음 원칙을 지켜라
- 관심사 분리
- 액티비티나 프래그먼트등 UI 상호작용, 운영체제 상호작용 로직만 담아라.
- DRIVE UI FROM MODEL - UI를 그릴때 모델을 기반으로 그려라
모델이 결국 데이터 처리를 담당하는 구성요소로,
앱 구성요소, 뷰 객체와 독립되어 생명주기 문제 X- 지속적인 모델을 제작하면 OS영향을 받지 않는다.
네트워크 연결 취약, 연결 불가 상태에서도 앱 작동 보장.
액티비티→ 복잡 → 유지보수 힘듦 → 테스트 힘듦 → 유지보수 힘듦
객체지향은 시스템을 상호작용하는 자율적인 객체로 본다.
-
자율적인 객체들은 시스템의 행위를 구현하기 위해 서로 메시지를 보내며 협력하며, 협력 과정에서 정해진 역할에 관련된 책임을 수행한다.
-
MVVM에서 모델, 뷰, 뷰모델의 역할을 명시한 컴포넌트이고 해당 역할은 역할에 대한 책임을 수행하는 객체들이 한다.
-
각 역할이자 컴포넌트를 책임이자 객체로 봐야한다.
ACTIVITY
- 하나의 함수를 상태와 행위를 가지는 객체로 만들자.
그럼 일단 행위부터 분리하자.
메소드는 하나의 일을 할 수 있도록 만들자.
메소드가 하나의 일을 해야하는 이유 생각해보자
목표 : 하나의 메소드에 오직 한단계의 들여쓰기만 한다.
이중 이프문, 이중 포문 X
- 메소드 10줄 넘기지 마라 메소드를 최대한 작게 쪼개어 관리하라.
