Android Architecture 패턴(MVP, MVC, MVVM) 요약 정리

소프트웨어 아키텍처는 소프트웨어 시스템과 그러한 구조 및 시스템을 생성하는 규율에 대해 추론하는 데 필요한 일련의 구조입니다

각 구조는 소프트웨어 요소, 요소 간의 관계, 요소와 관계의 속성으로 구성됩니다.

소프트웨어 시스템의 아키텍처는 건물의 아키텍처와 비슷합니다. 이는 시스템 및 개발 프로젝트의 청사진 역할을 하며 프로젝트 관리는 나중에 관련 팀과 사람들이 실행하는 데 필요한 작업을 추정하는 데 사용할 수 있습니다.

소프트웨어 아키텍처는 일단 구현되면 변경하는 데 비용이 많이 들기 때문에 근본적인 구조적 선택을 하는 것이 중요합니다.

소프트웨어 아키텍처 선택에는 소프트웨어 설계 가능성의 특정 구조 옵션이 포함됩니다.

예를 들어, 우주 왕복선 발사체를 제어하는 시스템은 매우 빠르고 매우 안정적이어야 한다는 요구 사항이 있었습니다. 따라서 적절한 실시간 컴퓨팅 언어를 선택해야 합니다. 또한 신뢰성에 대한 요구를 충족시키기 위해 중복되고 독립적으로 생성된 프로그램 복사본을 여러 개 보유하고 이러한 복사본을 독립적인 하드웨어에서 실행하면서 결과를 교차 확인하도록 선택할 수 있습니다.

소프트웨어 아키텍처를 문서화하면 이해 관계자 간의 커뮤니케이션이 용이해지고 상위 수준 설계에 대한 초기 결정을 캡처하며 프로젝트 간에 설계 구성 요소를 재사용할 수 있습니다.

 

1.  MVC( Model-View-Controller)

 

Model

- 데이터를 가지며 애플리케이션에서 사용되는 데이터와 그 데이터를 처리

- View 또는 Control에 대해 독립적어야 하며 재사용을 목표로 한다.

- 비지니스 로직의 대상.

 

View

- Android 기준, (XML, compose)등 실제 화면에 해당한다.

- 상호작용에서 Controller와 통신함.

- 유저가 어떤 입력(Action)을 하든 View는 보여주는것에 충실해야 한다.

 

Controller

- 사용자로부터 입력을 받고 이 입력을 모델에 의해 View 정의를 하게 됨.

- 모델의 데이터 변화에 따라 뷰를 선택 및 업데이트 한다. 

 

Android는 View와 Controller가 UI Controller(Activity/Fragement)에 포함되어 있습니다.
이러한 특성 때문에 UI Controller에 많은 코드들이 들어가고 거대 클래스가 생기는 현상이 발생하게 됩니다.

장점

 - 소규모 토이 프로젝트에는 적합한 형태

-  아키텍처가 단순하기에 구현 및 이해가 쉽다.

-  개발의 속도 또한 빠르다.

단점

- Controller와 View가 결합되어 있기 때문에 UnitTest에 어려움이 있습니다. UI 로직과 Controller에서 실행하는 로직들을 분리하기 어렵기 때문입니다.

- UI 변경점이 있을 때, Controller의 코드가 종속적으로 같이 변경되는 경우가 있습니다.

- Model과 View의 의존성이 높기 때문에 앱이 확장되고 복잡할수록 스파게티 코드가 될 위험이 높아집니다(MVP의 등장 배경).

현재 android에서는 UI Controller에서 MVC 모든 참조를 필요로 하고 거대화 되는 문제점이 있기에 잘 사용되지 않는다.

 

2.  MVP( Model-View-Presenter)

MVP의 특징은 Activity/Fragment가 View의 역할만 한다는 겁니다.
Android에 있어서 MVP는 컴포넌트 분리가 좀더 명확하게 이루어졌다고 할 수 있습니다.

 

Model

- 비즈니스 로직 및 데이터 Status입니다. 

- 데이터를 가져오고 조작합니다.

- 데이터베이스, Presenter 와 상호 작용합니다.

- View와 상호 작용하지 않습니다.

 

View (UI)

- UI, Activity/Fragment 구성됩니다.

- Presenter 상호 작용합니다.

- Model 상호 작용하지 않습니다.

 

Presenter(중재자)

- Interface로 구현된다.(UnitTest에 좀 더 효과적이다.)

 - Model의 데이터를 View에 제공하고, View를 업데이트한다

 - Model과 View간의 모든 상호 작용은 Presenter가 처리합니다. 데이터를 모델에 다시 저장합니다. 

 - 앱에서 표시하려는 모든 동작을 제어합니다.  

 

장점

- Model과 View의 의존성이 줄어듭니다.

- View가 보여주는 역활에만 충실합니다.

- UI와 Data파트가 명확히 구분되어 테스트가 용이합니다.

단점

- App이 커질수록 View와 Presenter 사이의 의존성이 강해집니다.

- 기능이 많아지면 Presenter의 비중이 커지기 때문에 분리하기가 어렵습니다.

 

MVC와 다르게 명확하게 컴포넌트가 구분되기에 의존성 및 테스트에서 용이하지만,

Presenter와 View가 1:1 관계를 갖고 있기로 많은 사용자 화면을 가지는 앱이라면 코드량이 증가한다.

복잡한 View는 Presenter의 결합도 강해진다.

 

1.  MVVM( Model-View-ViewModel)

Activity/Fragment에 수가 늘어남에 따라 같이 늘어나는 Presenter를  해결한다.

 

각 구성 요소 간의 긴밀한 결합도를 줄인다.

the concept of observables에 대한 개념을 도입한다..

각 요소는 observables 항목에 의한 참조만 있습니다.

 

Observer Pattern
객체의 상태 변화가 있을 때마다 함수 통하여 상태변화를 직접 옵저버들에게 알립니다.

옵저버들은 전달받은 상태를 이용하여 동기화및 작업을 수행한다. 

Model 

- 비즈니스 로직, 로컬 및 원격 데이터 소스 및 저장소를 포함합니다.

- Repository: ViewModel의 요청에 따라 로컬 또는 원격 데이터 소스와 통신합니다.

View 

- ViewModel의 데이터들을 구독(관찰)하고 있다가 객체가 변할 때 UI를 업데이트합니다.

- 사용자와 상호 작용만 합니다. 비지니스 로직은 절대 들어가선 안됩니다.

- 사용자의 행동을 ViewModel로 직접 전달하되 그에 대한 반응은 직접 받지 않습니다.

- 데이터를 관찰하고 있다가 변화하면 업데이트 하는 형식으로 반응을 처리합니다.

ViewModel 

- 대부분의 사용자 인터페이스 로직이 여기에 집중됩니다. 

- View와 비즈니스 논리 사이의 다리역활을 합니다.

 - 어떤 View에서 자신이 제공하는 데이터가 사용해야 하는지 전혀 알 수 없습니다.(View에 종속되지 않고 1:N 구조를 갖습니다.)

 - View에 대한 직접적인 참조가 없습니다. 따라서 테스트에 적합하고 결합이 느슨합니다.

 

그러나 여전히 Observable이 수행하는 이 상호 작용의 UI를 업데이트해야 합니다. 데이터가 변경되면 observable이 알립니다.

 

장점

- View와 Model이 완전히 독립적입니다.

- 데이터 바인딩을 사용하면 때문에 코드의 양이 감소합니다.

- ViewModel에서 View 코드가 없기 때문에 UnitTest를 쉽게 할 수 있습니다.

단점

- 데이터 바인딩이 필수적으로 요구됩니다.

- 간단한 UI에서 ViewModel을 설계해야 하고, 한 화면에 많은 ViewModel이 요구됩니다.

- 다양한 곳에서 많은 데이터를 받기 때문에 관리를 제대로 못 할 경우 버그가 발생