[Android] 디자인 패턴(MVC, MVP, MVVM)

Arkiee·2022년 11월 7일

Android

목록 보기

1/3

디자인 패턴을 공부하기 전에, 우선 '소프트웨어 공학'이라는 것을 알아야합니다.
소프트웨어 공학이란, 소프트웨어의 개발/운용/유지보수 등의 생명주기 전반을 체계적이고 서술적이며 정랼적으로 다루는 학문입니다. 즉, 공학을 소프트웨어에 적용하는 것입니다.

디자인 패턴 또한 소프트웨어 공학에서 특정 문맥에 공통적으로 발생하는 문제에 대해 재사용이 가능하게 만들어놓은 해결책입니다.

개발자들이 애플리케이션/시스템을 디자인할 때 발생하는 공통된 문제들을 해결하기 위해 사용됩니다.

안드로이드 앱을 논리적 구성 요소들로 체계화하려는 노력은 지속되어 왔습니다. 가장 기초적인 MVC(Model View Controller) 패턴으로 시작해서 더 모듈화되고 테스트 가능한 패턴으로 발전해왔습니다.

대표적으로는 MVP(Model View Presenter)와 MVVM(Model View ViewModel)이 가장 많이 사용되며 어느게 더 좋다는 정답은 없습니다. 각 디자인패턴의 특장점은 확실하고 상황에 따른 방법론의 선택이 중요한 것 같습니다.

Model: Application의 두뇌라고 볼 수 있습니다. 데이터 + 상태 + 비즈니스 로직을 다룹니다. View나 Controller에 묶여 있지 않아 재사용이 가능합니다.
View: 모델의 내용들을 표현해줍니다. 사용자가 Application을 사용할 때 Controller와 통신합니다. 하지만 MVC에서 View는 모델에 대한 지식이 없고 사용자와 application이 상호작용을 할 때 수행하는 작업을 이해하지 못합니다.
Controller: Model과 View의 중간에서 데이터 변경이나 상호작용을 관리해 View나 Model을 업데이트시켜줍니다.
동작
1. 사용자의 Action이 Controller에 들어온다
2. Controller는 사용자의 Action을 확인하고, Model을 업데이트한다.
3. Controller는 Model을 나타내줄 View를 선택한다.
4. View는 Model을 이용해 화면을 나타낸다.
특징
- Controller는 여러 개의 View를 선택할 수 있는 1:N구조이다.
- Controller는 View를 선택할 뿐 직접 업데이트하지 않는다.(View는 Controller를 모른다)
- View와 Model을 완벽하게 분리하고, Model테스트가 용이하다
단점
- Controller가 Android API에 종속되어 테스트가 어렵다.
- View를 변경하면 Controller도 변경해야 한다.
- 많은 코드들이 Controller에 집중되면 성능이 저하되고 유지보수가 어려워진다.

MVC의 문제점을 해결하기 위해 나온 패턴으로 일단 Controller를 분리해서 책임을 줄이고 View와 Activity/Fragment가 자연스럽게 결합되도록 만들었습니다.

Model: MVC의 Model과 같은 역할을 합니다.
View: ActivityFragment가 View의 일부분으로 간주됩니다. Activity가 View Interface를 implements하여 이를 통해 특정 View에 결합하는 것을 제거하고 View의 모의 구현으로 단위 테스트가 가능해집니다.
Presenter: MVC의 Controller의 역할이지만 View에 전혀 연결되어 있지 않은 인터페이스입니다. 이를 통해 모듈성, 유연성 문제뿐만 아니라 테스트 가능성 문제를 해결합니다.
동작
1. 사용자의 Action이 View를 통해 들어온다.
2. View는 data를 Presenter에게 요청한다.
3. Presenter는 Model에게 data를 요청한다.
4. Model은 Presenter에게 요청받은 data를 반환한다.
5. Presenter는 View에게 data를 반환한다.
특징
- Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 역할을 한다.
- Presenter와 View는 1:1관계이다.
- 단순 Interface이기 때문에 테스트가 용이하고 모듈화/유연성 문제가 해결되었다.
단점
- View와 Presenter간의 의존성이 높다
- Android API를 참조해서는 안된다.(권장)
- Controller와 같이 코드가 집중되면 성능이 저하되고 유지보수가 어려워진다.

MVVM은 Data-binding을 사용해 더 쉬운 테스트 및 모듈화의 이점을 동시에 제공하고 View + Model을 연결하기 위해 작성하는 Glue 코드 양을 줄여 줍니다.

흔히 말하는 객체지향 디자인패턴의 옵져버 패턴을 본떠 만든 구조같습니다. 옵져버의 역할은 ViewModel이라는 친구가 하게 됩니다.

Model: MVC의 Model과 같습니다. 기존 모델에 business logic을 추가하기 위해 MVVM에 SquareParams라는 Model을 추가했습니다. DB사용이나 Retrofit을 통한 백엔드 API 호출 등을 주로 수행합니다.
View: 가변적인 방식으로 ViewModel에 의해 노출되는 관찰 가능한 변수 및 작업에 바인딩됩니다. (ViewModel을 관찰해 UI를 갱신)
ViewModel: Model을 wrapping하고 View에 필요한 관찰 가능한 데이터를 준비합니다. 또한 View가 이벤트(evnet)를 Model에 전달하기 위한 hooks(BindingAdapter)를 제공합니다. 하지만, ViewModel은 View에 연결되어 있지 않습니다.

동작
1. 사용자의 Action들은 View를 통해 들어오게 된다.
2. Command pattern으로 ViewModel에 Action을 전달한다.
3. ViewModel은 Model에게 data를 요청한다.
4. ViewModel은 응답받은 data를 가공해 저장한다.
5. View는 ViewModel과 Data Binding해 화면을 나타낸다.
특징
- Command Pattern과 Data Binding을 사용해 구분한다.
- View와 Model 사이의 의존성이 없다.
- View와 ViewModel 사이의 의존성도 없다.
- 위처럼 모든 부분이 독립적이므로 모듈화가 가능하다.
단점
- ViewModel의 설계가 어렵다.
- View가 변수와 표현식 모두에 Binding 될 수 있으므로 갈수록 presentation logic이 늘어나 XML이 방대해진다. 이것을 방지하려면 항상 ViewModel에서 직접 값을 가져오는 것이 좋다.

MVP와 MVVM 모두 앱을 모듈화하고 단일 책임 요소를 분할하는데 MVC보다 더 나은 작업을 수행하지만 Application에 더 많은 복잡성을 추가하게 됩니다. 오히려 앱이 간단하고 라이브하지 않다면 MVC가 더 적합할 것입니다.

중요한 것은 현재 개발하는 Application에 최적의 구조를 스스로 응용해 만들 수 있어야 한다는 것..!

저 또한 지금까지 MVC, MVP를 이용한 개발만을 해왔기에 이번 공부 기회에 MVVM에 대해서 더 자세히 알아보고 직접 코드를 작성해봐야겠습니다.

꿈을 꾸는 개발자