아키텍처 패턴은 왜 쓰는 걸까?
위키 백과에 따르면 아래와 같은 이유가 있다.
아키텍처 패턴(architectural pattern)은 주어진 문맥 안에서 소프트웨어 아키텍처의 공통적인 발생 문제에 대한 일반적인, 재사용 가능한 해결책을 의미한다. 아키텍처 패턴은 소프트웨어 디자인 패턴과 비슷하지만 더 넓은 범위에 속한다.
조금 더 자세하게 알아보면 아래와 같은 이점이 있다.
- 코드의 이해도 증가
- 복잡한 구조의 단순화
- 다양한 에러에 대한 해결 방안 도출
- 용이한 유지보수 및 효율적인 코드
MVC
개요
MVC는 Controller로 모든 입력을 받고 이벤트가 발생한 Controller에 의해 모듈의 정의와 View의 용도가 결정된다.
MVC의 장점
빠른 개발 속도와 코드의 이해도가 높다.
일단 view와 model이 분리되어 있기 때문에 model을 재사용할 수 있다.
단순한 기능만 제공하는 화면이라면 mvc를 사용하여 개발 기간을 단축시키는 것도 좋은 방법이 될 것 같다.
MVC의 단점
코드의 양이 증가하고 서로 밀접한 관계를 가지는 구조가 생길 가능성이 매우 높아진다.
그에 따라 당연히 유지보수도 힘들어지고 테스트 코드 작성이 힘들어진다.
MVP
개요
MVP는 View와 Model을 서로 분리하고 서로 간의 상호작용을 Presenter에 위임하여 서로의 의존성을 낮추도록 고안된 디자인 패턴이다.
MVP의 경우 presenter와 view가 1 : 1 관계를 가진다.
우선 Presenter에 대해 조금 더 알아보자.
Presenter
- Model과 View사이의 중간자 역할로 모델과 뷰에 상호작용한다는 점에서 MVC패턴의 Controller와 유사하지만 View에 직접적인 연결이 아닌 ‘인터페이스’를 통해 상호작용한다.
- 인터페이스를 통해 상호작용하므로 MVC가 가지는 테스트 문제와 유연성이 해결된다.
- 뷰에게는 표시할 data만 전달하는 역할만 하고 표현은 View에서 이루어진다.
MVP의 장점
MVC에 비해 코드의 가독성을 증가시킬 수 있고 Model과 View 간 결합도를 낮춤으로 유지 보수 시 해당하는 부분만 코드 수정을 하면 되므로 확장성이 증가하고 테스트 코드를 작성하기가 비교적 편리해진다.
MVP의 단점
View와 Presenter은 1:1 관계이기 때문에 Presenter가 View에 의존성이 강하다.
애플리케이션의 기능이 계속해서 추가되거나 복잡해질수록 View와 Presenter 간 의존성이 강해지는 현상이 생긴다.
또한 시간이 지남에 따라 Presenter는 거대한 코드량을 가지게 되고 문제가 발생하기 쉬워질 수 있다.
MVVM
개요
최대한 기능적으로 작은 단위로 나누어 테스트가 용이하고 큰 규모의 프로젝트도 상대적으로 관리하기 좋은 구조이다.
모든 입력은 View로 전달되어 ViewModel은 입력에 해당하는 Presentation Logic을 처리하여 View에 데이터를 전달
한다. 하지만 ViewModel은 MVP 패턴과는 다르게 View를 모르므로 1:n의 관계를 가질 수 있다.
MVVM의 장점
로직의 변경으로 인한 사이드 이펙트를 줄일 수 있고 변경에 유연한 상태의 코드를 만들 수 있다. Model과 View 사이, ViewModel과 View 사이의 상호 간 의존성이 없어지므로 테스트하기 쉬워지고 테스트 시 모델이 변경되는 시점에 관찰 중인 변수가 예상하는 값으로 설정되었는지 확인하면 된다.
MVVM의 단점
View가 변수와 표현식 모두에 바인딩될 수 있으므로 시간이 지남에 따라 관계없는 Presentation Logic이 늘어나고 이를 보완하기 위해 xml에 코드를 추가하게 된다. 이때 난해하게 코드가 증가하면 유지 보수가 힘들어질 수 있다. 또한, 소형 앱에서 사용하기에는 오버헤드일 수 있다.
그럼 MVC, MVP, MVVM의 명확한 차이는??
MVC 패턴의 경우는 명확하게 MVP와 MVVM과 차이가 난다.
입력이 Controller로 들어오면 Controller는 Model을 조작하고 조작된 Model을 다시 View에게 전달한다.
Model을 직접 사용하거나 Model에서 View에게 Notify 해주는 방법, View에서 Polling을 통해 Model의 변화를 알아채는 방법 등이 있다.
이로 인해 View와 Model은 서로 간의 의존성을 피하기 쉽지 않다.
MVP와 MVVM는 Presenter와 Viewmodel이 수행하는 로직은 큰 차이가 있진 않지만 명확하게 구분할 수 있는 차이점이 존재한다.
먼저 MVP를 알아보자.
Presenter는 View의 인스턴스를 가지고 있고 1:1의 관계를 가지고 View에서 입력이 처리된다.
그에 해당하는 Model의 인스턴스도 Presenter가 가지고 있기 때문에 View와 Model의 중간다리 역할을 한다.
MVP에서 주목할 점은 View가 수동적이라는 점이다.
View는 스스로 데이터를 반영하지 않고 명령을 받는다. 명령을 하는 주체인 Presenter가 View에게 명령을 하는 형태인 것이다. (데이터를 출력해라 - view.showData(data))
동작 방식은 View에서 이벤트가 발생하면 Presenter에 전달하고 Presenter는 해당 이벤트에 따른 Model을 조작하고 그 결과를 바인딩(혹은 명령)을 통해 View에게 통보하여 View를 업데이트한다.
이렇게 Presenter를 통해 view와 model을 분리해줄 수 있기 때문에 View는 Model을 몰라도 된다.
그럼 MVVM을 알아보자.
ViewModel 뷰 모델 말 그대로 View를 나타내 주기 위한 Model이라고 생각하면 된다. View보다는 Model과 유사하게 디자인되며, View의 바인딩될 때 가장 강력하다.
MVP와 같이 View에서 입력이 처리된다.
MVVM은 MVP와는 반대로 View가 능동적이다.
View는 스스로 ViewModel 객체의 어떤 데이터가 필요한지 직접 관찰한다.
관찰하기 위해서는 ViewModel에 있는 데이터가 관찰 가능한 형태여야 한다. Google에서 제공한 LiveData, ObservableField 객체를 쓰거나 Rx Java에서 제공해주는 Observable 객체도 사용 가능하다.
MVVM 패턴의 가장 큰 장점이라 함은 Command와 Data Binding으로 MVP 패턴과 달리 View와의 의존성을 완벽히 분리할 수 있다는 장점이 있다.
Command를 통하여 Behavior를 View의 특정한 ViewAction(Event)와 연결할 수 있으며, ViewModel의 속성과 특정 View의 속성을 Binding 시켜 줌으로써 ViewModel 속성이 변경될 때마다 View를 업데이트시켜줄 수 있다.
요약
- MVP는 수동적(Passive) View, MVVM 능동적(Active) View
- model 조작 후 MVP는 Presenter가 View에 변경된 data 노출을 명령, MVVM은 View가 ViewModel의 데이터 관찰 후 변경 시 변경된 data를 노출
- MVP는 View에 매우 의존적임. 하지만 MVVM은 View와 완벽히 분리됨
'Android' 카테고리의 다른 글
[안드로이드] Module 수준의 Gradle (0) | 2021.03.18 |
---|---|
[안드로이드] Room (0) | 2021.03.17 |
[안드로이드] Androidx에서 File 공유하기 (0) | 2020.12.15 |
[안드로이드] Invoke-customs are only supported starting with Android O (--min-api 26) 에러 해결 방법 (0) | 2020.12.04 |
[안드로이드] 프로세스와 스레드의 차이점 (0) | 2020.11.30 |