티스토리 뷰

반응형

MVVM (Model-View-ViewModel) 패턴은 비즈니스 로직과 사용자 인터페이스(UI)를 완전히 분리함으로써 쉬운 유지관리와 테스트를 진행할 수 있으며 기본적으로 모듈화를 진행하기 때문에 코드 재사용성도 뛰어납니다. 

 

기존의 액티비티(Activity)에 비즈니스 로직과 UI 로직과 같은 복잡한 기능을 넣게 되면 액티비티가 무거워지고 종속성이 너무 강해 테스트가 힘들고 유지보수가 힘들어집니다. MVVM 패턴은 기본적으로 Model과 View 그리고 ViewModel과 같이 각자의 역할에 맡는 기능들을 모듈화하기 때문에 유지관리 및 테스트가 용이해집니다. 


1. View

View는 Activity나 Fragment 같은 화면에 표현되는 레이아웃을 정의합니다. View는 기본적으로 비즈니스 로직을 포함하지 않지만 UI 변경과 관련된 일부 로직은 포함될 수 있습니다. 

2. ViewModel

뷰모델(ViewModel)은 View가 데이터 바인딩(Data Binding)할 수 있는 속성과 명령으로 구성되어 있습니다. 기본적으로 View는 ViewModel을 옵저빙하고 있다가 상태 변화가 전달되면 화면을 갱신해야 합니다. 

3. Model

모델(Model)은 데이터베이스와 같은 여러 데이터 소스로부터 ViewModel이 요청하는 데이터를 준비하는 역할을 합니다. 

4. 관계

View는 ViewModel에 대한 Reference를 가지지만 ViewModel은 View에 대한 Reference를 가지지 않습니다. ViewModel은 Model을 알고있으나 View는 알지 못합니다. 사용자로부터 특정 데이터 변경과 관련하여 이벤트가 발생하게 되면 View에서 직접 Model을 참조하지 않습니다. View는 UI를 갱신하는 역할만 하고 대신 ViewModel의 관찰 가능한 데이터를 옵저빙하면서 상태 변화에 반응만 합니다. Model을 알고있는 ViewModel이 Model의 데이터를 참조하여 관찰 가능한 데이터를 변경하게되고 View에서는 해당 데이터가 변경되었다는 것을 감지하고 화면을 갱신합니다. 

 

View가 데이터 변경을 기다렸다가 화면을 갱신하는 것과 같이 수동적인 포지션을 취하는 경우가 많지만 꼭 그렇지만은 않습니다. Two-way-Binding과 같이 View가 능동적인 포지션을 취하는 경우도 있습니다. 

5. AAC(Android Architecture Component)

AAC(Android Architecture Component)는 모듈화된 코딩을 돕기 위해 DataBinding, LiveData등과 같이 MVVM 아키텍처를 설계하는데 있어 유용한 라이브러리를 제공하고 있습니다. 물론 MVVM 자체가 디자인 패턴이기 때문에 AAC 라이브러리를 사용하지 않고도 MVVM 패턴 설계가 가능합니다. 다만 Activity나 Fragment의 여러 LifeCycle에 따라 데이터의 상태 관리를 하는 측측면에서 AAC 라이브러리를 사용할 경우 이러한 lifeCycle을 신경쓰지 않고 ViewModel의 데이터를 처리할 수 있습니다. 

6. 마치며 ...

나름 구글링을 통해 MVVM 패턴에 대해 공부하면서 실제 프로젝트에도 적용해본 경험이 있습니다. 그래도 막연한 부분이 아직 없지 않아 있기 때문에 제대로 패턴을 적용시켰는지는 사실 자신이 없네요. 블로그에 글을 정리하면서 다시 MVVM 패턴에 대해 공부를 해나갈 생각입니다. 나름 정리한 내용 중 잘못된 부분이 있다면 많은 피드백 주시면 감사하겠습니다!

 

7. 참조

https://docs.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm

반응형