아키텍처
- 앱 전체에 대한 구조이다.
- 아키텍처가 잘 구성되어 있으면 코드의 가독성이 높아지고 재사용이 용이해지고 기능 확장이 쉬워진다.
관심사
- 어떠한 상태나 데이터에 영향을 미치는 정보의 집합
- 관심사가 잘 분리되면 모듈들이 독립적으로 서로 의존성이 낮다는 의미
- 즉, 모듈의 재사용성이 좋아져 생산성이 올라간다.
안드로이드 설계 패턴
- 안드로이드 앱 개발을 할 때 자주 사용하는 아키텍처 구조를 디자인 패턴화한 MVC, MVP, MVVM, MVI가 있다.
- 사용자에게 UI를 제공하고 상호작용을 하는 View와 데이터를 저장하고 관리하는 Model 부분은 동일하나 Controller냐 Presenter냐, ViewModel이냐 Intent냐에 따라서 조금씩 패턴이 다르다.
MVC
구조
- 이 패턴은 View가 상호작용하는 게 아니라 Controller랑 상호작용한다.
- 사용자는 Controller에게 요청을 하고 Controller는 이에 대한 적절한 요청을 Model에게 한다. Model이 데이터를 변경하고 View에게 알리면 View가 이에 대응하여 UI를 변경한다.
- View - Model 관계를 observer로 구현하기도 한다.
장단점
- 가장 단순하고 많이 사용하는 패턴
- View와 Controller부분이 Activity나 Fragment에 작성이 되어서 코드가 방대해진다는 단점이 있다.
- View가 Model을 아는 구조라서 서로 의존성이 높다.
- Controller만 따로 유닛 테스트를 하지 못한다.
MVP
구조
- View와 Controller, Model이 너무 의존성이 높은 것을 낮추기 위해 Presenter가 View와 Model을 제어해주고 View와는 Contract라는 인터페이스를 통해서 서로 참조하는 형태로 의존성을 낮춘 구조
- Presenter - Model은 콜백형태로 데이터 변경을 Presenter에게 알려준다.
장단점
- Presenter가 UI 코드가 없어져서 따로 유닛 테스트가 가능해진다.
- 결국 interface를 통해서 View, Presenter가 서로 참조를 하고 있기에 1:1구조가 되어 View가 많아지면 Presenter도 같이 많아지는 문제점이 있음
MVVM
구조
- ViewModel이 View에서 사용할 수 있는 데이터를 가지고 있고 View가 ViewModel을 구독해서 데이터가 변경될 때마다 이를 감지하고 UI를 갱신하는 구조
- databinding 필수
- 구독이 가능한(Observable) 데이터 홀더 클래스인 LiveData나 StateFlow 사용
장단점
- ViewModel은 View를 알지 못하기에 의존성이 낮아지고 View:ViewModel이 n:1 구조가 가능해짐
- AAC ViewModel은 MVVM의 ViewModel과는 관계가 없지만 Activity보다 생명주기가 길어서 Configuration Change일 때도 데이터를 잃지 않는다는 장점이 있어서 보통 이 ViewModel을 사용한다.
MVI
구조
- compose가 도입되면서 상태관리가 중요해짐 (recomposition이 안 되거나 또는 너무 자주 일어나거나)
- View를 통해 어떤 이벤트를 사용자가 요청하면 사용자의 의도 (intent)가 Model을 변경한다.
- 그럼 Model은 새로운 불변의 상태로 변경된다.
- 그러나 데이터 변경 과정에서 상태에 큰 영향을 주지않는 액티비티 이동, 토스트 메시지 등등의 이벤트가 필요할 수 있다.
- 이러한 것들은 부수효과로 따로 처리해준다.
장단점
- 항상 하나의 불변 상태가 존재하기에 상태 관리가 쉽고 스레드에 안전하다
- 데이터가 단방향으로 흐른다.
- 작은 변경도 intent로 처리해야 한다.
Frontend Developer