7. 안드로이드 디자인 패턴 - MVP & MVVM

안드로이드 개발을 처음 했을 때는 activity fragment 에 모든 코드 작성했었다. 어떤 식으로 나눠야 하는지, 구조를 짜야 하는지 잘 몰랐기 때문에 그랬던 것 같다. 이후로 코드의 효율성과 유지보수를 위해 디자인 패턴에 대해서 공부했고, 지금은 MVVM 패턴을 사용한 프로젝트도 진행 중에 있다. 

 

이전에도 같은 주제로 러프하게 글을 작성했던 적이 있지만 그 당시보다 지금 디자인 패턴에 대한 이해도가 높아졌다는 생각이 들어서 다시 한번 정리해보려 한다. 이번 글에서는 MVP, MVVM 패턴을 다룬다.

 

---

 

MVP 패턴 : Mode + View + Presenter  

UI 와 비지니스 로직을 분리하고 서로 간의 상호작용에 Presenter 를 사용하는 패턴으로 UI를 담당하는 View 와 비지니스 로직을 담당하는 Model의 서로 간의 의존성을 최소화 하는 것에 집중한다. View에서 user action 이 감지되면 그 이벤트를 present에게 전달한다. 전달받은 presenter는 model과 상호작용을 통해 상태를 확인하고 처리된 데이터를 다시 받은 view는 view에게 데이터를 전달하는 플로우다. 

 

Model 은 프로그램 내부적으로 쓰이는 데이터를 저장하고 처리한다. 다른 두 요소에 의존적이지 않고 독립적인 특징을 보인다. 

View 는 UIViewController의 역할을 하는데 여기서 앞에서 말한 user action (input 등)을 받고 그 결과를 보여준다. Model에서 처리되 데이터를 Presenter 를 통해 받아 유저에게 보여주는 플로우로 Presenter에게 매우 의존적일 수 밖에 없는 구조다. 

Presenter는 View에서 input이 들어오면 그것을 받아서 처리하고 다시 View로 보내준다. 여기서 Presenter는 데이터만 전달하며 보여주는 방식은 View가 결정한다. 이는 View와 일대일 관계를 가지고 있으며 인터페이스를 통해 상호작용한다는 특징이 있다. 

 

 

이전의 방식보다 효율적이고 체계적인 MVP 패턴이었지만, 여전히 복잡하고, 코드가 늘어날 경우 View 와 Presenter의 의존성이 강해진다는 단점이 있었다. 이를 보완한 것이 MVVM 패턴이다.

 

 

MVVM 패턴 : Model + View + ViewModel

View와 Model 이 분리되어 있고 분리된 로직 사이에 View의 이벤트에 따라 Model이 데이터를 반환하거나 저장하도록 하는 ViewModel이 존재하는 패턴이다. 

 

ViewModel 은 관계도를 그렸을 때 View 에게서 들어오는 화살표를 있지만 View로 나가는 화살표는 없다. View를 그리는 것에는 관여하지 않고 그냥 데이터만 바꿔주며, 그렇게 바뀐 데이터는 view가 직접 보고 확인해서 화면을 그리게 된다. 

View는 MVP 패턴과 같이 user action을 받는다. ViewModel의 데이터를 관찰해서 UI를 갱신하고 데이터의 변화를 알아차려 자동으로 화면을 갱신할 수 있다. 여기서 live data, observe 같은 관찰 방법이 주로 사용된다. 

Model은 MVP와 역할이 거의 동일하며 DB 사용이나 retrofit을 이용한 backend api 호출이 보편적이다. 

 

 

 

직접 코드를 짜보고 개발하고 난 후에 디자인 패턴을 다시 정리하니 훨씬 이해도가 높아진다. 하지만 아직 완벽하게 원리를 이해했다고 말하기는 부족하다는 생각이 든다. 완전히 이해했다는 생각이 들 떄 다시 한번 정리해볼 것이다.