이제 왜 MVVM을 사용해야 하는지 궁금하실 것입니다
이제 매우 복잡해지기 시작하는데 이렇게 하는 이유를 확실히 아셨으면
좋겠습니다
그렇지 않으면 이렇게 하고 싶지 않으실 것이기 때문입니다
이는 제가 MVVM을 보면서 자주 느끼는 것인데 추상화가
너무 많고 설정할 것도 많기 때문입니다
이 추상화가 왜 좋은 방법인가에 대한 이유입니다
첫 번째는 고려 사항의 분리입니다
MVVM은 사용자 인터페이스와 비즈니스 로직 그리고 데이터를 깔끔하게 분리하여
각 컴포넌트가 다른 일을 하게 해서 코드가 정리되고
유지가 쉽게 합니다
두 번째는 테스트가 용이합니다
이 분리 덕분에 각 컴포넌트를 개별적으로 테스트할 수 있습니다
예를 들어 사용자 인터페이스나 데이터 소스의 관여 없이 뷰 모델을 테스트할 수
있습니다
세 번째는 재사용성 입니다
뷰 모델은 뷰로 부터 분리되었는데 이는 같은 뷰 모델을 다른 뷰나 심지어는 다른 플랫폼에서도
재사용할 수 있다는 뜻입니다
만약 멀티 플랫폼 앱을 개발한다면 데이터 바인딩이 있는데
MVVM은 데이터 바인딩 메커니즘과 결합해서 뷰 모델과 뷰 사이의 자동 업데이트가
가능합니다
이는 보일러 플레이트 코드를 줄여주며 UI가 항상 데이터와 동기화될 수 있도록 해줍니다 다섯 번째는
유지보수 입니다
애플리케이션이 커지면 구분된 계층을 갖는 것이 복잡성을 관리하는데 도움이 됩니다
사용자 인터페이스의 변경이 기본적인 비즈니스 로직 등에 영향을 주지 않습니다
이 것이 MVVM이 타당한 이유입니다
이제 저장소에 대해 볼 텐데 이미 저장소를 사용해 보았고
다음 몇 강의에서 더 자세히 알아볼 것입니다
저장소는 나머지 애플리케이션에 데이터가 접근하는 클린 aPI처럼 행동하는 디자인 패턴입니다
Remote API와 같은 데이터 소스와 로컬 데이터베이스 그리고 인 메모리 캐시간의 중재자라고
생각하십시오
저장소 사용의 이점은 추상화로 미가공 데이터 소스에 높은 수준의 추상화를 제공하고
애플리케이션의 다른 부분을 바꾸지 않고도 데이터 소스를 변경할 수
있게 합니다
예를 들어 웹에서 데이터를 얻는다고 합시다
좋습니다
이제 더 이상 웹에서 데이터를 얻지 않고 예를 들어 데이터 베이스에서 얻습니다
이 것도 좋습니다
문제가 되지 않습니다
플러그 앤 플레이 입니다
이 전에 이야기했던 것처럼 말입니다 그리고 데이터 관리를 집중화 합니다
운영과 관련된 모든 데이터는 저장소에 집중되어 지속성을 보장하고 중복을 방지합니다
세 번째는 격리입니다
코드와 연관된 데이터를 저장소에 격리 시켜 테스트를 위해 데이터를 쉽게 변경할 수 있고
데이터 저장 메커니즘을 바꾸거나 앱의 다른 부분에 영향을 주지 않고 캐싱 계층을 추가할 수 있습니다
네 번째는 유연성입니다
예를 들어 미래에 데이터를 가져오는 방법이나 저장 방법을 바꾸거나
데이터 베이스를 변경하거나 클라우드 기반 백업을 추가한다면
뷰나 뷰 모델을 만지지 않고 저장소만 변경하면 됩니다
간단한 비유를 보겠습니다
여러분이 레스토랑의 셰프이고 뷰는 텃밭이나 지역 마트 농장 등의
다양한 장소에서 오는 요리 재료라고 상상해 보십시오
이 것들이 다른 데이터 소스들 입니다
요리할 때마다 이 장소에 직접 가는 대신 저장소라는 신뢰하는
공급자가 있어 최고의 재료를 가져다 줍니다
공급자는 각 재료를 어디서 가져와야 하는지 언제 수확하고 어떻게 저장할 지 알고 있습니다
여러분은 셰프입니다
뷰는 음식에 맞는 재료를 받는 지만 신경 쓰면 됩니다
공급자가 재료 출처의 복잡성을 추상화시켜 여러분은 요리에 집중할 수 있습니다
비슷하게 앱 개발에서는 저장소가 데이터 소스의 복잡성을 다루고
뷰 모델과 뷰는 원시적인 책임에 집중할 수 있게 합니다
MVVM 저장소 패턴은 복잡해 보일 수는 있으나 특히 큰 애플리케이션에 대해서
장기적인 이점을 제공합니다
이 구조적 접근은 복잡한 것을 관리하고 확장 가능성을 보장하며 유지 보수를 수월하게 해주는 이점이 있습니다
강의의 현재 시점에서는 조금 과할 수는 있으나 왜 사용하는 지를
이해하는 것이 중요합니다 왜냐하면 애플리케이션을 실제로 다시 실행할 수 있게
하기 위해 MainActivity에서 이용 가능하게 설정해야 하기 때문입니다