[Android] Architecture Pattern

개발자들이 안드로이드 앱을 안정적으로 만들 수 있도록 아키텍쳐(Android App Architecture)라는 가이드 제공
-> AAC 컴포넌트를 활용하면 더 견고한, 고품질의 앱을 만들 수 있다.

 

우선 아키텍쳐 패턴부터 살펴보자!

소프트웨어 아키텍쳐 패턴(Software Architecture Pattern)
자주 발생하는 문제를 해결하기 위해 반복적으로 사용가능한 구조를 만들었는데 이를 아키텍쳐 패턴이라고 한다.
Android 에선 MVC, MVP, MVVM 패턴을 주로 사용

핵심목적: 관심사 분리 ->  코드의 안정성 + 확장 가능

 

---

MVC Pattern

• 안드로이드 특성상 액티비티가 View 표시와 Controller 역할을 같이 수행해야 하기 때문에 두 요소의 결합도가 높아짐
• 많은 코드가 Controller로 모이게 되어 액티비티가 비대해짐
  • Unit 테스트나 기능 추가가 용이하지 않게되는 문제

model

데이터와 비지니스 로직(UI와 관련 없는 로직)
앱의 UI와 관계없는 부분

view

사용자에게 보여주는 UI 화면
android 에선 xml 레이아웃이 mvc의 view 에 해당함

controller

view와 model 사이의 상호작용을 관리

프레젠테이션 로직을 가지고 있음

android의 activity를 의미

 

MVC의 경우에는 안드로이드에서 적용할 때 View와 Controller가 Activity에서 모두 처리되어야하기 때문에 Activity가 커지는 문제가 있어서 관심사의 분리가 비교적 원활하지 않다고 여겨진다.

---

MVP Pattern

• View와 Model 사이의 데이터 흐름이 사라지고 Presenter가 중간에서 데이터 흐름을 제어
• 인터페이스를 추가로 구현해야 하기 때문에 구현비용이 올라가게 됨

 

model

 

view

presenter의 참조가 있음

mvc에선 컨트롤러 + 뷰를 겸했던 액티비티 or 프래그먼트가

mvp 에서는 온전한 view로 간주됨

presenter

mvc의 컨트롤러와 동일한역할을 함

 

presenter 가 중간에서 관리하도록 변경됨

뷰의 참조를 직접하지 않고 인터페이스 사용 -> 느슨한 결합

뷰와 모델의 참조를 가져서

뷰로부터 액션 전달받고 필요한경우 모델로부터데이터 취득해서 뷰에 전달

---

MVVM Pattern

• View 와 Model 사이의 의존성이 없으며, ViewModel도 View에 의존성을 가지지 않음
• 참조는 View -> ViewModel -> Model 순으로 단방향으로만 일어남 -> 유지보수 용이

 

model

데이터와 비지니스 로직(UI와 관련 없는 로직)
앱의 UI와 관계없는 부분

veiw

e. g ) activity

사용자에게 보여지는 UI 파트

데이터 바인딩을 통해서 view model을 통해 일방적으로 통지받은 데이터를 표시하는 역할만 함

뷰가 viewmodel을 옵저빙 함으로서 UI 갱신

 

view model

view를 만드는데 필요한 로직이 들어있음

view를 참조 x -> viewmodel과 view 1:N 관계 -> 중복되는 코드를 viewmodel로 묶어서 줄일 수 있음

---

안드로이드 앱 아키텍쳐 

일반적인 안드로이드의 MVVM 패턴은

구글에서 권장하는 안드로이드 아키텍쳐 컴포넌트를 활용한 mvvm패턴의 like 패턴이다.

MVVM 패턴은 Model, View, ViewModel을 분리해 뷰와 모델간의 의존성을 줄여준다.

 

이런 구조가 된다면 뷰는 모델이, 모델은 뷰가 어떻게 동작하는지와 상관없이 로직을 작성할 수 있고 뷰모델을 통해 데이터를 통신할 수 있게 된다.

 

View

1. Activity / Fragment 가 View 역할을 함
2. 사용자의 Action 을 받음 (텍스트 입력, 버튼 터치 등)
3. ViewModel 의 데이터를 관찰하여 UI 갱신

 

ViewModel

1. View 가 요청한 데이터를 Model 로 요청함
2. Model 로부터 요청한 데이터를 받음

 

Model

1. ViewModel 이 요청한 데이터를 반환함
2. Room, Realm 과 같은 DB 사용이나 Retrofit 을 통한 백엔드 API 호출 (네트워킹) 이 보편적

 

결국 View 가 필요로 하는 데이터는 ViewModel 이 쥐고 있고,
View 는 그것을 필요로 하기 때문에 ViewModel 이 쥐고 있는 데이터를 관찰 (Observing) 한다.

때문에 MVC 패턴과 다르게, View 가 DB 에 직접 접근하는 것이 아닌 UI 업데이트에만 집중한다.
또한 관찰하고 있는 만큼 데이터 변화에 더욱 능동적으로 움직이게 된다.

 

뷰모델의 장점은 아래와 같다

• View 가 ViewModel 의 Data 를 관찰하고 있으므로 UI 업데이트가 간편
• ViewModel 이 데이터를 홀드하고 있으므로 Memory Leak 발생 가능성 배제
  (View 가 직접 Model 에 접근하지 않아 Activity / Fragment 라이프 사이클에 의존하지 않기 때문)
• 기능별 모듈화가 잘 되어 유지 보수에 용이 (e.g. ViewModel 재사용 및 DB 교체 등의 작업이 편리함)

 

 

참조 링크

https://developer.android.com/jetpack/guide?hl=ko

dddooo9블로그

해로님의블로그

 

최근 적용되고있는 클린아키텍처

UI Layer : view, viewmodel

domain Layer: activity가 비대해지는것을 막기위해 viewmodel채용 -> viewmodel이 비대해지는 문제

-> viewmodel에서 비즈니스로직만 분리해서 -> domain layer(use case)

 

domain layer가 추가되면서

-> mvvm like구조보다는 Clean Architecture에 가까워짐