Android 디자인패턴별 장단점 비교 (MVC, MVP, MVI, MVVM, SVG)

MVC 패턴

 View  <--  Controller  -->  Model 

 

1. 모든 입력은 Controller로 전달되고

2. Controller는 입력에 해당하는 Model을 업데이트한다

3. 업데이트 결과에 따라 Controller는 View를 선택한다 (1:N구조)

4. View를 업데이트하기위해 View가 Model을 직접이용하거나 Model에서 View에서 notify하여 업데이트

 

결국 View를 업데이트하기 위해서는 결국 M-V사이에 의존성이 생기게 된다 안드로이드는 Activity에서 View와 Controller모두 처리하기때문에 적합하지 않음

MVP 패턴

 View  <-->  Presenter  <-->  Model 

MVP는 Model, View, Presenter 로 구성되어있으며

 

View : Input UI라 할수있고 Button, Text등의 Event를 Presenter에게 전달하여 Model에 요청을한다

Presenter : View 와 Model의 중간자 역할을하며 View에서온 Event를 토대로 Model에 데이터를 요청하고, Model에서 받은 데이터를 View에 적용해준다

Model : DataBase나 Network Request같은 비지니스 로직을 담당

 

주의

View는 본래 정보를 보여주는 역할과 사용자의 Event를 전달하는 것이 주요 역할이다

하지만 Presenter를 참조하 이는 View에서 비지니스로직에 관여하는 가능성이 커진다는 얘기다

MVP로 앱을만든다면 View와 비지니스 로직이 결합되지 않도록 해야한다.

 

유지보수 : MVP에서는 View와 Presenter를 위한 interface를 1대1로 매번만들어야하고, 메소드의 추가,변경시마다 두개의 파일을 수정해야함

 

디버깅 : XML을 제외한 로직이 java로 되어있기떄문에 원하는 위치에 브레이크 포인트를 걸어서 확인이 가능하고 IDE에서 제공하는 기능을 활용가능

 

테스트 : Presneter의 비지니스 로직에 따라 원하는 View함수가 제대로불리는 지확인, 무난한편

MVVM 패턴

 View  -->  ViewModel  -->  Model 

MVVM은 Model, View, ViewModel 로 구성되어있으며

 

View : UI이고 데이터 바인딩을 사용해 ViewModel을 Observing한다

ViewModel : Model에 데이터를 요청하는 것은 Presenter와 똑같으나 데이터 바인딩을 통해 View에 데이터변경을 알려준다

Model : DataBase나 Network Request같은 비지니스 로직을 담당

 

기존의 방법으로 데이터를 적용하려면 findViewById같이 참조를 통해 데이터를 적용하는데 데이터바인딩을통하면

알아서 데이터와 View를 결합시켜준다 하지만 이를위해 XML에 별도에 문법으로 작성해야하고 데이터를 자동으로 매핑해주는 편리함을 가지고있다

그러나 특정 필드가 여러 View에서 참조하는 경우 View들을 찾기위해서는 수동으로 검색해야한다(ide 기능 사용불가)

 

적용하는 방법이 다양하기때문에 설계할때 규칙을 정하거나 구조에대해 이야기하고 진행하는 것이 좋다

 

유지보수 : XML을 수정해야할때 가장 어렵다. 수정이 필요한경우 ViewModel의 파악 XML안에 로직을 파악해야하기떄문

디버깅 : 데이터바인딩을 사용하는경우 XML안에 로직은 브레이크 포인트가 걸리지않는다 java파일로 자동생성되기때문, 수정 포인트를 찾는것이 어렵고, XML이 변경되면 브레이킹 포인트도 다시잡아야한다.

 

테스트 : XML에 선언한 값, 로직은 테스트대상에서 제외하고 ViewModel에 정의한 데이터가 정확한지 확인

가독성은 MVP보다 떨어진다 

MVI 패턴

 View  -->  Intent  --> Model   -->  View 

순환구조

View : View를 나타내며 하나 이상의 Activity나 Fragment로 구현된다

Intent : 사용자 또는 앱내에서 발생하는 Action을 나타냅니다. 모든 Action에 대해 View는 Intent를 수신한다

Model : 모델은 상태를 나타낸다 MVI의 모델은 아키텍쳐의 다른 레이어와 단방향 데이터 흐름을 보장하기 위해 변경이 불가해야한다 

 

model은 불변하기 때문에 앱을 새로운 상태로 바꾸기 위해서는 새로운 모델을 만들어야한다, 이때문에 이전상태의 정보가 필요한 경우 이전 상태와 새로운 intents를 합쳐서 새 상태로 병합한다.

 

장점 데이터가 단방향으로 순환하기때문에 예측 가능한 상태

view의 생명주기 동안 일관성 있는 상태를 갖습니다.

불변 model은 큰앱과 멀티스레드 안정성과 안정적인 동작을 제고합니다.

 

단점은 학습곡선이 높다는 것이다 rxjava와 멀티스레드 지식이 필요하기때문

SVC 패턴

            Screen                 

 Views  -->  ControlTower  -->  Model 

SVC는 Screen, VIews, ControlTower, Model로 구성된다

SVC는 Activity와 Fragment를 SVC로 나누는 것으로 시작

Screen : Activity, Fragment에서 라이프사이클, intent, startActivity, onOptionsItemSelected같은 화면 관련 로직

Views : 내부 뷰에게 데이터를 전달하고 표시, 유저가 뷰를 컨트롤하는것을 ControlTower에 알림

ControlTower : 각 스크린에서 발생하는 이벤트를 감지, 발생한이벤트에 맞게 필요한 조치를 한다.

 

Views내부에서 작업할때 비지니스 로직은 생각안해도됨

MVP에서 중복작업하던 인터페이서 재생성을 안해도됨

MVVM에서 명령 수행을 위한 Command 필드를 만들필요가없다.

 

유지보수 : MVP에서 불편했던 인터페이스 중복생성은 없으나 View에서 일어나는 이벤트를 정의하는 것이 추가적인 일로 느껴질수 있다