[Android] MVVM 패턴

MVVM 패턴? 그게 뭔데??

사실 이러한 디자인 패턴 없이도 어떠한 프로젝트나 서비스를 운영하는 게 가능하다. 그렇다면, 왜 이러한 디자인 패턴이 계속 이슈화되는 것일까?

예를 들어 설명하자면, 패턴 없이 하나의 서비스를 구현하여 앱을 출시했다고 가정하자. 출시하기 전에 당연히 테스트를 마쳤을 것이고, 실제 출시 후 오류가 발생하지 않았다고 하자.
오류에 대한 이슈는 없지만, 만약 실제 사용자들이 기능에 대한 업데이트를 요구한다면? 실제 업데이트를 진행하려고 할 때 구조화되어 있지 않은 코드에서 새로운 기능을 추가하는 일은 쉽지 않을 것이다. 간단한 작업이어도 리소스가 많이 필요해지고, 심한 경우 하나의 코드를 추가하기 위해 전체를 바꿔야 할 수도 있다.

 

위의 예시처럼, 여러 가지의 기능들이 분리(구조화)되어 있지 않아 유지보수가 힘들어지는 상황을 해결하기 위해 패턴이 등장하였다. MVC, MVP 등 다양한 패턴들이 존재하지만 오늘은 MVVM에 대해서 알아보려 한다.

 

MVVM (Model-View-ViewModel)

MVVM 패턴은 Model, View, ViewModel을 분리해 뷰에 모델 간의 의존성을 줄인다.

 

뷰(Activity/Fragment)와 모델(Repository)이 분리되어 있고, 이 사이에 뷰의 이벤트에 따라 모델의 데이터가 변경되도록 통신하는 뷰모델이 존재한다. 위 구조를 이룬다면 뷰는 모델이, 모델은 뷰가 어떻게 동작하는지와 상관없이 로직을 작성할 수 있고 뷰모델을 통해 데이터를 통신할 수 있게 된다.

 

MVVM의 선택 이유?

위에서 언급했듯이, MVVM 외에도 MVC, MVP 등 다양한 패턴들이 존재한다.
MVC의 경우 안드로이드에 적용할 때 View와 Controller가 Activity에서 모두 처리되어야 하기 때문에 Activity가 커지는 문제가 있어서 관심사의 분리가 비교적 원활하지 않다.
MVP는 Presenter가 뷰와 1대 1로 동작하기 때문에 뷰와 프레젠터의 의존성이 강해지는 문제가 발생하고 이에 따라 종종 프레젠터의 로직이 비대해지는 문제가 발생한다.

그러므로, View와 Model을 충분히 분리할 수 있고, 화면회전 등의 동작으로 뷰가 다시 생성되어도 ViewModel을 통해 데이터를 유지할 수 있는 MVVM 방식이 좋다고 생각했다.

 

위 패턴들에 대한 이야기는 이전 포스팅에서 다룬 적이 있다.

https://ystech.tistory.com/entry/Android-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4-MVCMVPMVVM

[Android] 디자인 패턴 - MVC/MVP/MVVM

 

MVVM의 목표

• 코드의 분리
• 재사용 가능한 코드 활용
• 테스트를 통해 로직에 대한 오류 예측

 

MVVM 활용 기술

• AAC-ViewModel
• Coroutines, Retrofit2, LiveData, DataBinding
• 추가 학습 필요 : Room, Flow 등

 

마치며

오늘은 MVVM에 관해 정리를 해보았다. 사실 정리를 하게 된 계기가 실제 프로젝트에 MVVM 패턴을 적용시켜보려 했지만, 막상 적용하려니 어려워서 다시 처음부터 정리해 보자라는 느낌으로 정리해 보았다.

 

정리를 하기 위해 공부를 해보니 기존에 활용하려고 공부했던 LiveData, DataBinding, Coroutines 등도 부족하다고 느꼈고, 이외에도 Room, Flow 등 추가로 공부해야 될 것도 많았다. 부족한 부분을 공부하여 효율적인 코드 관리를 해보자!

 

새로운 기술 너무 어려워😪

 

Reference

• https://developer.android.com/jetpack/guide?gclid=Cj0KCQiA4b2MBhD2ARIsAIrcB-R6TL4d-KXTwXoLs-juzsvCadVFqBiP06TD6jHGsht9wfd4JtbR8kcaAo1YEALw_wcB&gclsrc=aw.ds&hl=ko#common-principles

앱 아키텍처 가이드  |  Android 개발자  |  Android Developers