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

• 소프트웨어 공학에서 특정 문맥에 공통적으로 발생하는 문제에 대해 재사용이 가능하게 만든 해결책
• 코드를 효율적으로 작성하기 위한 방법론
• 궁극적으로 건강한 소프트웨어 개발을 위한 방법론
• MVC, MVP, MVVM

---

 💡 MVC (Model View Presenter)

• View
  • 사용자에게 보이는 UI를 나타낸다.
  • Model로부터 Data를 박아 사용자에게 보여준다.
• 애플리케이션에서
  • 사용되는 Data를 처리한다.
  • View에 의존적이지 않기 때문에 재사용이 가능하다.
• Controller
  • 사용자의 입력(action)을 받고 처리한다.
  • 주로 Activity나 Fragment로 표현된다.
  • Model의 Data변화에 따라 View를 선택한다.
• 동작
  • 사용자의 Action이 Controller에 들어온다.
  • Controller는 사용자의 Action을 확인하고, Model을 업데이트한다.
  • Controller는 Model을 나타내줄 View를 선택한다.(4) View는 Model을 이용하여 화면을 나타낸다.
• 특징
  • Controller는 여러 개의 View를 선택할 수 있는 1:N 구조이다.
  • Controller는 View를 선택할 뿐 직접 업데이트하지 않는다.(View는 Controller를 모른다)
  • View와 Model을 완벽하게 분리하고, Model 테스트가 용이하다.
• 단점
  • Controller가 Android API에 종속되어 테스트가 어렵다.
  • View를 변경하면 Controller도 변경해야 한다.
  • 많은 코드들이 Controller에 집중되면 성능이 저하되고 유지보수가 어려워진다.

 

---

💡 MVP(Model View Presenter)

• View
  • 기본적인 것들은 MVC와 동일하나, Activity/Fragment가 View에 포함된다.
  • View를 관리하는 Interface를 추가하여 Presenter를 독립적으로 만들어준다.
• Model
  • 어플리케이션에서 사용되는 data와 상태에 대한 business logic을 처리한다.
  • View에 의존적이지 않기 때문에 재사용이 가능하다.
• Presenter
  • View와 Model 사이에서 data를 가공하고 전달하는 역할을 수행한다.
  • View가 요청한 정보를 Model로부터 받고 가공하여 View에게 전달한다.
  • Controller와의 차이점은 Interface라는 점이다.
• 동작
  • 사용자의 Action이 View를 통해 들어온다.
  • View는 data를 Presenter에게 요청한다.
  • Presenter는 Model에게 data를 요청한다.
  • Model은 Presenter에게 요청받은 data를 반환한다.
  • Presenter는 View에게 data를 반환한다.
• 특징
  • Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 역할을 한다.
  • Presenter와 View는 1:1 관계이다.
  • 단순 Interface이기 때문에 테스트가 용이하고 모듈화/유연성 문제가 해결되었다.
• 단점
  • View와 Presenter 간의 의존성이 높다.
  • Android API를 참조해서는 안된다.(권장)
  • Controller와 같이 코드가 집중되면 성능이 저하되고 유지보수가 어려워진다.

---

💡 MVVM (Model View ViewModel)

• View
  • 기본적인 것들은 MVC와 동일하나, Activity/Fragment가 View에 포함된다.
  • ViewModel을 관찰하여 UI를 갱신한다.
  • Data Binding을 위해 gradle과 xml을 수정해야 한다.
  • 이를 통해 View는 ViewModel에 의해 Model과 유연한 binding이 가능하게 된다.
• Model
  • MVC, MVP와 동일하다.
  • 기존 모델에 business logic을 추가하기 위해 MVVM에 SquareParams라는 Model을 추가했다.
  • DB 사용이나 Retrofit을 통한 백엔드 API 호출 등을 주로 수행한다.
• ViewModel
  • 기본적으로 View에 종속되지 않고 그래서는 안된다.
  • Model을 래핑하고 View에 필요한 Observable data를 준비한다.
  • View가 Model에 Event를 전달할 수 있도록 Hook(BindingAdapter)을 준비한다.
• 동작
  • 사용자의 Action들은 View를 통해 들어오게 된다.
  • Command pattern으로 ViewModel에 Action을 전달한다.
  • ViewModel은 Model에게 data를 요청한다.
  • ViewModel은 응답받은 data를 가공하여 저장한다.
  • View는 ViewModel과 Data Binding 하여 화면을 나타낸다.
• 특징
  • Command Pattern과 Data Binding을 사용하여 구현한다.
  • View와 Model 사이의 의존성이 없다.
  • View와 ViewModel 사이의 의존성도 없다.
  • 위처럼 모든 부분이 독립적이므로 모듈화가 가능하다.
• 단점
  • ViewModel의 설계가 어렵다.
  • View가 변수와 표현식 모두에 Binding 될 수 있으므로 갈수록 presentation logic이 늘어나 XML이 방대해진다. 이것을 방지하려면 항상 ViewModel에서 직접 값을 가져오는 것이 좋다.