[Android] MVC vs MVP vs MVVM

내용 및 이미지 참고 : https://academy.realm.io/kr/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/ 

안드로이드의 MVC, MVP, MVVM 종합 안내서

 

MVC

 

컨트롤러 문제점

• 테스트 용이성 - 컨트롤러가 안드로이드 API에 깊게 종속되므로 유닛 테스트가 어렵다.
• 모듈화 및 유연성 - 컨트롤러가 뷰에 단단히 결합되며, 뷰의 확장일 수도 있다. 뷰를 변경하면 컨트롤러로 돌아가서 변경해야 한다. => View와 Model의 결합도가 높다
• 유지 보수 - 시간이 지남에 따라 보다 많은 코드가 컨트롤러로 모이면서 비대해지고 문제가 발생하기 쉬워진다.

 

MVP

View

유일한 변화는 액티비티/프래그먼트가 이제 뷰의 일부로 간주

액티비티가 뷰 인터페이스를 구현해서 프리젠터가 코드를 만들 인터페이스를 갖도록 하는 것이 좋다. 이렇게 하면 특정 뷰와 결합되지 않고 가상 뷰를 구현해서 간단한 유닛 테스트를 실행할 수 있다.

 

Presenter

본질적으로는 MVC의 컨트롤러와 같지만, 뷰에 연결되는 것이 아니라 그냥 인터페이스라는 점이 다르다. 

이에 따라 MVC가 가진 테스트 가능성 문제와 함께 모듈화/유연성 문제 역시 해결된다.

극단적으로 MVP를 따르는 사람들은 프리젠터가 절대로 어떤 안드로이드 API나 코드라도 참조해서는 안된다고 주장한다.

 

장점

Presenter는 안드로이드 고유의 뷰와 API에 연결되지 않으며, View 인터페이스를 기반으로 한 가상 객체를 만들어서 프리젠터의 뷰와의 상호작용을 테스트 할 수 있다

 

문제점

• 유지 보수 - 컨트롤러처럼 프리젠터에도 시간이 지남에 따라 추가 비즈니스 로직이 모이는 경향이 있다. 시간이 흐른 후 개발자는 거대하고 다루기 어려운데다 문제가 발생하기 쉽고 분리하기도 어려운 프리젠터를 발견하게 된다.
• View - Presenter 1:1로 강한 결합을 가져 Presenter를 재활용하는 데 어려움이 있다. (View가 Presenter를 이용해 데이터를 주고받기 때문에 Presenter에 매우 의존적) 

 

MVVM

View

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

 

ViewModel

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

→ ViewModel은 View를 참조 하지않음. View가 ViewModel을 구독해 관찰하는 구조로 느슨한 결합을 가짐. 특정 data가 여러 View에서 사용된다면 관련 logic이 담긴 ViewModel을 재활용할 수 있다.

 

장점

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

 

단점

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

 

MVVM