[Android] Android Design Pattern

출처 : https://academy.realm.io/kr/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/

Intro

안드로이드 앱을 논리적 구성 요소로 체계화하려는 방법이 지속적으로 발전하였다.
MVC 패턴을 초석으로 보다 모듈화되고 테스트 가능한 패턴으로 발전해 왔다.
MVP와 MVVM은 MVC를 대체하기 위한 대안책이다. 하지만 개발자들은 어떤 것이 안드로이드에 적합한지 의견을 일치하지 못했다.

---

MVC ( Model View Controller )

Model

• 앱의 데이터 + 상태 + 비즈니스 로직 이다.
• 앱의 두뇌역할이며 뷰나 컨트롤러에 묶이지 않으므로 많은 곳에서 재사용할 수 있다.

View

• 모델의 표현 이다.
• 사용자가 앱과 상호작용할 때 컨트롤러와 통신하는 책임을 맡는다.
• MVC 구조에서 뷰는 하위 모델에 대한 지식이나 상태에 대한 이해가 없고, 사용자가 버튼을 클릭하거나 값을 입력하는 등의 행동을 할 때 무엇을 해야 하는지 모른다.
• 뷰가 덜 알수록 모델에 종속되지 않으므로 보다 변화에 유연할 수 있다.

Controller

• 앱을 묶어주는 접착제 이다.
• 앱에서 발생하는 일을 담당하는 마스터 컨트롤러 역할이다.
• 모델에서 데이터가 변화되는 것에 따라 컨트롤러는 뷰의 상태를 적절하게 업데이트하도록 결정할 수 있다.
• 주로 액티비티나 프래그먼트로 표현된다.

평가

• MVC는 훌륭하게 모델과 뷰를 분리해준다. 모델은 어디에도 종속되지 않으며, 뷰는 유닛 테스트 레벨에서 그다지 테스트할 것이 거의 없어서 쉽게 모델을 테스트 할 수 있다.

컨트롤러 문제점

• 테스트 용이성 : 컨트롤러가 안드로이드 API에 깊게 종속되므로 유닛 테스트가 어렵다.
• 모듈화 및 유연성 : 컨트롤러가 뷰에 단단히 결합되며, 뷰의 확장일 수도 있다. 뷰를 변경하면 컨트롤러로 돌아가서 변경해야 한다.
• 유지 보수 : 시간이 지남에 따라 보다 많은 코드가 컨트롤러로 모이면서 비대해지고 문제가 발생하기 쉬워진다. 특히 anemic models 모델을 사용하는 앱은 더욱 그렇다.

---

MVP ( Model View Presenter )

• 컨트롤러의 책임에 묶이지 않고도 뷰와 액티비티가 자연스럽게 결합하도록 한다.

Model

• MVC와 동일하며 변화가 없다.

View

• 액티비티와 프래그먼트가 뷰의 일부로 간주된다.
• 액티비티가 뷰 인터페이스를 구현해서 프리젠터가 코드를 만들 인터페이스를 갖도록 하는 것이 좋다.
• 특정 뷰와 결합되지 않고 가상 뷰를 구현해서 간단한 유닛 테스트가 가능하다.

Presenter

• 본질적으로 MVC의 컨트롤러와 같지만, 뷰에 연결되는 것이 아니라 그냥 인터페이스 일뿐이다.
• 이에 따라 MVC가 가진 테스트 가능성 문제와 함께 모듈화/유연성 문제 역시 해결한다.

평가

• MVC보다 깔끔하다.
• 자체 인터페이스를 구현하면 어떤 뷰와도 작업할 수 있어서 프리젠터 로직을 쉽게 테스트 할 수 있다.

문제점

• 유지 보수 : 프리젠터에도 시간이 지남에 따라 비즈니스 로직이 모이게 된다.

---

MVVM ( Model View ViewModel )

• 안드로이드의 데이터 바인딩을 사용한다.
• 테스트와 모듈화가 쉽고 뷰와 모델을 연결하기 위해 사용해야 하는 연결 코드를 줄일 수 있다.

Model

• MVC와 동일하며 변화가 없다.

View

• 뷰모델에 의해 보여지는 옵저버블 변수와 액션에 유연하게 바인딩된다.

ViewModel

• 모델을 래핑하고 뷰에 필요한 옵저버블 데이터를 준비한다.
• 뷰가 모델에 이벤트를 전달할 수 있도록 훅(hook)을 준비한다.
• 뷰모델은 뷰에 종속되지 않는다.

평가

• 뷰에 대한 의존성이 전혀 없으므로 유닛 테스트가 더 쉬워진다.
• MVP 패턴에서처럼 테스트를 위한 가상 뷰를 만들 필요 없이, 테스트할 때 모델이 변경되는 시점에 옵저버블 변수가 제대로 설정됐는지 확인하면 된다.

문제점

• 유지 관리 : 뷰가 변수와 표현식 모두에 바인딩될 수 있으므로 시간이 지남에 따라 관계없는 프리젠테이션 로직이 늘어나 XML에 코드를 추가하게 될 수 있다. 이를 방지하려면 뷰 바인딩 표현식에서 값을 계산하거나 파생하지 말고 항상 뷰모델에서 직접 값을 가져오는 것이 좋다.

---

Epilogue

MVC에 비해 MVP와 MVVM은 앱을 보다 모듈화하고 구성 요소를 단일 용도로 분해한다는 점에서 발전된 모습이지만, 이 구조 때문에 앱이 더 복잡해질 수도 있다. 한 두개의 화면으로만 구성된 간단한 앱이라면 MVC만으로도 충분하다.
한편 데이터 바인딩을 사용하는 MVVM은 보다 반응이 빠른 프로그래밍 모델을 따르고 적은 코드를 사용한다는 점에서 매력적이다.