2023-12-11

Architecture

• 아키텍쳐를 사용하는 이유
  • 일관적인 코드작성 (유지보수, 협업 능률 상승)
  • 생산성 향상
  • 테스트의 용이성
  • 어플리케이션의 개발 방향성을 잡아줌 (동일한 목표)

• 아키텍쳐의 종류
  • MVC: model + view + controlller
  • MVP: model + view(viewController) + presenter
  • MVVM: model + view(viewController) + viewmodel
  • MVVM + DataBinding
  • MVI: model + view + intent
  • MvRx(framework-airbnb), Flux(framework-facebook), Ribs, etc....

MVP architecture

mvp 아키텍쳐
view - presenter - model 로 분리 된 아키텍쳐이다.

Model과 View는 MVC 패턴과 동일하고, Controller 대신 Presenter가 존재한다.
presenter를 통하여 비지니스 로직을 호출한다.

presenter는 모델에 직접 접근하여 데이터를 가공하여 view로 전달한다.
view와 model을 이어주는 중재자 역할을 한다.

동작 과정

1. 사용자의 액션은 View를 통해 들어온다.
2. View는 데이터를 직접 Presenter에 요청한다.
3. Presenter는 Model에게 직접 데이터를 요청한다.
4. Model은 Presenter에서 요청받은 데이터를 가공하여 응답한다.
5. Presenter는 View에게 데이터를 응답한다.
6. View는 Presenter가 응답한 데이터를 이용하여 화면에 나타낸다.

특징
중재자인 Presenter는 view와 model의 인스턴스를 가지고 있어 둘을 연결 할 수 있다.
presenter와 view는 1:1로 설정한다.

장점
MVC의 단점인 view - model 사이의 의존성을 해결하였다.

단점
view - model 사이의 의존성은 해결되었지만, 1:1로 관계를 맺고있는 view - presenter사이의
의존성이 높아진다.

MVVM architecture

mvvm 아키텍쳐
view -viewModel - model로 분리 된 아키텍쳐이다.
Model과 View는 MVP 패턴과 동일하고, Presenter 대신 ViewModel이 존재한다.
ViewModel을 통하여 비지니스 로직을 호출한다.

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

MVP는 Presenter가 View와 1대1로 동작하기 때문에 View와 Presenter의 의존성이 강해지는 문제가 발생하고 이에 따라 종종 프레젠터의 로직이 무거워지는 문제가 발생하기도 했다.

이를 해결하기 위해여 MVVM아키텍쳐가 사용되기 시작하였다.

특징
Model, View는 역할이 동일하고, ViewModel은 View를 표현하기 위해 만든 View를 위한 Model이다. View를 나타내 주기 위한 Model이자 View를 나타내기 위한 데이터 처리하는 역할을 한다.

옵저버패턴과 DataBinding을 통해 view와 viewmodel사이의 의존성을 없애주었다.
즉, view는 viewmodel을 호출하고 바라보기만 할 뿐이다. 이외의 참조를 하지않는다.
view와 ViewModel은 N:1의 관계를 갖는다.

장점
MVVM 패턴은 View와 Model 사이의 의존성이 없다. 또한 옵저버 패턴 또는 Data Binding을 사용하여 View와 View Model 사이의 의존성 또한 없앤 디자인패턴이다. 각각의 부분은 독립적이기 때문에 모듈화 하여 개발할 수 있다.

단점
MVVM 패턴의 단점은 View Model의 설계가 어렵다.(패턴 적용)

google architecture 문서

구글에서 권장하는 아키텍쳐 가이드이다.

일반 아키텍쳐 원칙

1. 관심사 분리
   따라야 할 가장 중요한 원칙은 관심사 분리입니다. Activity 또는 Fragment에 모든 코드를 작성하는 실수는 흔히 일어납니다. 이러한 UI 기반의 클래스는 UI 및 운영체제 상호작용을 처리하는 로직만 포함해야 합니다. 이러한 클래스를 최대한 가볍게 유지하여 구성요소 수명 주기와 관련된 많은 문제를 피하고 그러한 클래스의 테스트 가능성을 개선할 수 있습니다.
   
   Activity 및 Fragment 구현은 소유 대상이 아니며 Android OS와 앱 사이의 계약을 나타내도록 이어주는 클래스일 뿐입니다. OS는 사용자 상호작용을 기반으로 또는 메모리 부족과 같은 시스템 조건으로 인해 언제든지 클래스를 제거할 수 있습니다. 만족스러운 사용자 환경과 더욱 수월한 앱 관리 환경을 제공하려면 이러한 클래스에 대한 의존성을 최소화하는 것이 좋습니다.
   
   
2. 데이터 모델에서 UI 도출하기
   또 하나의 중요한 원칙은 데이터 모델에서 UI를 도출해야 한다는 것입니다. 가급적 지속적인 모델을 권장합니다. 데이터 모델은 앱의 데이터를 나타냅니다. 이들은 앱의 UI 요소 및 기타 구성요소와 독립되어 있습니다. 즉, 이들은 UI 및 앱 구성요소 수명 주기와는 관련이 없습니다. 하지만 OS에서 메모리에서 앱의 프로세스를 삭제하기로 결정하면 여전히 삭제됩니다.
   
   지속 모델이 이상적인 이유는 다음과 같습니다.
   
   Android OS에서 리소스를 확보하기 위해 앱을 제거해도 사용자 데이터가 삭제되지 않습니다.
   네트워크 연결이 취약하거나 연결되어 있지 않아도 앱이 계속 작동합니다.
   앱 아키텍처를 데이터 모델 클래스에 기반하는 경우 앱의 테스트 가능성과 견고성이 더 높아집니다.