MVVM 아키텍처를 이용하여 작은 Application Project를 만들고, 사용하면서 느낀점을 정리합니다.
잘못된 정보나 수정할 사항 or 피드백은 언제든 환영합니다.
MVVM
안드로이드의 MVVM아키텍처의 처리과정
Android Developer에서 AAC와 함께 소개되었던 MVVM아키텍처
: Model, View, ViewModel이 역할을 가진 layer로 나뉘어져 각자의 역할에 맞는 기능을 수행합니다.
장점 :
- layer를 나눠서 각 계층이 역할을 명확하게 가져갑니다. (각 계층에 구성된 객체가 하나의 책임을 가짐 - 단일책임원칙)
- 미리 구조화시켜놓은 계층은 통일성 있는 코드를 만들 수 있습니다. (협업에 효율적)
- ViewModel에 View 관련(android.* 패키지) 클래스를 import하지 않습니다. Model과 View의 의존성이 약해졌다는 증거라 생각합니다.
- jetpack의 AAC에 포함된 library들이 MVVM에서 특히 사용 및 관리를 효과적으로 할 수 있게 설계되어졌다고 느꼈습니다. (구글에서 더 좋은 기능들을 개발 및 지원할 가능성이 큼)
- 분리된 역할에 따라 테스트가 용이해집니다. (Testable한 코드 지향)
ex) DataBinding -> xml에 데이터를 바인딩하여 데이터 객체와 뷰컴포넌트간 데이터 전달이 가능
: viewmodel에 ViewComponent 코드 차단 가능하게 함
LiveDate -> ViewComponent에서 데이터 감지
: 바인딩한 viewmodel의 데이터를 간접적으로 사용 가능하게하여 데이터와 뷰의 분리 실현 MVP와 차이점
: MVP패턴의 경우 View와 Model간의 상호작용을 Presenter를 매개로 동작합니다.
- Presenter와 View간의 loose coupling을 위한 interface구성
- MVP: Presenter와 View가 서로를 바라보고 기능 수행 vs MVVM: ViewModel은 데이터 변형과 비즈니스 로직에 대한 처리 + View는 화면의 IO만 관리하고 ViewModel을 관찰하며 결과 수행
( 개인적인 생각 )
그러나 View에서 입출력에 대한 내용을 Presenter에게 전달해야하는 과정에서 결합도가 올라감
MVP의 경우 Presenter라는 매개를 거쳐야만 하는 것이 단점으로 작용할 수 있음ex) 텍스트입력 후 입력한 데이터와 함께 화면전환 ( view에서 input받은 데이터 -> presenter로 데이터 전달하여 model 데이터 변경 -> 변경된 데이터 화면 전달 -> Intent or Bundle에 담아 화면 전환 ) 필요없는 과정이 추가될 수 있음MVP와 MVVM 모두 애플리케이션을 만들기 위해 layer를 만들고 각 계층에 맞는 코드를 작성하게 하여 코드의 통일성과 이슈트래킹을 효과적으로 할 수 있는 디자인패턴들이라 생각함
복잡도가 높거나 높아질 가능성이 큰 프로젝트일수록 각 객체들간의 역할이 명확해야함 (부수효과를 막기 위해)
숙련도가 떨어져도 디자인 패턴에 맞추어서 작업을 했을 때 가장 명확한 책임을 가지게 만드는 패턴이 효과적인 패턴이라 생각함
패턴에 숙련되는 과정은 mvvm이 더 어렵다고 느껴짐, 대신 패턴이 지향하는 목표는 mvvm이 더 적합하다고 생각
- 디자인패턴에 집중하는 것이 아니라 더 객체지향적으로 코딩하기 위해서 어떻게 사용하는 것이 더 적합할 것인지를 고민할 것
(개인프로젝트에서는 MVVM 활용 예정)
Sample Project : https://github.com/sysout-achieve/SearchImage
