Tech Log

[Architecture Pattern] MVVM 패턴 본문

Design Pattern

[Architecture Pattern] MVVM 패턴

yuhee kim 2022. 8. 30. 19:40

안드로이드를 개발할 때 가장 많이 권장된다는, 구글이 권장하는.., MVVM 패턴을 공부해보고자 한다. 아키텍처 패턴이 각각의 장단점이 있지만, MVVM이 어떻길래 권장되는지 상당히 궁금했다.

 

해당 포스팅은 안드로이드 아키텍처 기준으로 작성되었습니다.

 

1. MVVM 패턴이란?

MVVM 패턴은 Model, View, ViewModel로 세 가지 역할로 프로그램을 분담하여 나눈 것이다.

안드로이드에서의 MVC 패턴은 View와 Model 사이의 의존성이 높다.

그리고 MVC 패턴에서는 View와 Controller가 함께 Activity나 Fragment에 있다.... 

(이에 대한 자세한 예시는 추후에 MVC 패턴 예제 포스팅을 작성해볼 예정이다)

 

이렇게 두 모듈 간의 결합도가 높으면, 추후에 프로그램이 커졌을 때 유지보수가 어려워지는 경향이 있다.

기능이 추가되었을 때, 의존성이 높은 모듈끼리 영향이 잘 미치게 된다.

(기능을 수정을 할 때도 마찬가지이다)

 

MVP(Model, View, Presenter) 패턴도 있으나 이 또한 프로그램이 복잡해질 수록, View와 Presenter 사이의 의존성이 높아진다는 단점이 있다.

 

MVVM 패턴은 MVC, MVP 패턴과 달리 각각의 부분이 의존성이 높지 않다.

(이렇기 때문에 프로그램이 커질 수록 MVVM 패턴이 권장되는 것 같다)

 

각 역할들 간의 의존성을 없애기 위해 MVVM 패턴을 사용한다.

 

2. MVVM 패턴의 구조

MVVM패턴은 Model, View, ViewModel 세 가지로 나뉜다.

출처 : http://kyubid.com/blog/understanding-mvvm-on-android-tutorial-05-introduction-to-reactive-programming-with-rxjava/

 

Model

  • 프로그램에서 다루는 데이터를 가지고 있고 그 데이터를 처리하는 부분
  • 데이터 처리하는 역할
  • 보통 API 호출, DataBase 사용이 이루어진다.
  • 안드로이드에서는 APIClient, Dao 등등

View

  • UI 부분
  • 사용자의 입력(Action)을 받는다.
    • 사용자 Action : ex)버튼 클릭, 아이템 목록 스크롤 등등
  • 데이터 처리 결과를 출력한다.
  • 렌더링하는 역할
  • ViewModel의 데이터를 처리하는 메소드를 호출한다.
    • ex) 버튼 누르면 viewModel.loadData()를 호출

ViewModel

  • Model로부터 데이터를 얻는다
  • 얻은 데이터를 View에 표시하기 위해 데이터 처리 과정을 시행한다.
    • 데이터 처리하는 메소드를 정의한다.
  • Model로부터 데이터를 얻기 위한 메소드를 정의한다.
  • 얻은 데이터를 View에 표시하기 위해 데이터를 처리하는 메소드를 정의한다(선택)

 

동작 순서

  1. View로부터 사용자의 입력이 들어온다.
  2. View에서 들어온 입력을 Command 패턴으로 ViewModel에 입력을 전달한다.
  3. ViewModel이 Model에게 데이터를 요청한다.
  4. Model은 ViewModel로부터 요청받은 데이터를 응답한다.
  5. ViewModel은 Model로부터 받은 데이터를 처리하여 저장한다.
  6. View는 ViewModel과 DataBinding으로 화면에 데이터를 나타낸다.

* Command 패턴 : 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴 (참고)

 

3. 장점

  • 각 역할의 의존성이 없다(다른 부분을 의식할 필요가 없다)
    • 효율적인 Unit Test 시행이 가능하다.
    • 모듈화 개발이 가능하다.
  • Model과 View 사이의 의존성이 없다.
  • View와 ViewModel 사이의 의존성이 없다.

 

4. 문제점

  • View가 커질 수록, ViewModel이 커질 수 있다.
  • 어플리케이션이 커지면 Data Binding 때문에 메모리 소모가 빨라진다.
  • ViewModel의 설계가 어렵다.
  • 단순한 프로젝트일 경우 적합하지 않은 패턴일 수 있다.

 

다른 디자인 패턴보다 복잡한 패턴이다.

단순한 로직을 가진 프로젝트에는 적합하지 않을 수가 있겠다.

역시나 어떤 기술이든, 패턴이든, 각각의 장단점이 있기 때문에 적재적소에 사용하는 것이 옳은 것 같다.

MVVM 또한 구글에서 권장했다고 해서 모든 프로젝트에 적용하는 것은 무리가 있어보인다.

 

참조
Comments