iOS - MVVM 패턴

MVVM (Model - View- ViewModel)

 

Model

• 데이터, 네트워크 로직, 비즈니스 로직등을 담으며 데이터를 캡슐화하는 역할을 맡고 있다.
• MVC 패턴의 Model과 크게 다르지 않다.

View

• 사용자에게 데이터를 보여주거나 UI를 담당한다.
• Model을 직접 알고 있어서는 안된다.
• View는 ViewModel로부터 데이터를 가져와서 표현한다.
• 사용자와 View의 상호작용을 수신하고 이에 대한 처리를 ViewModel에 부탁한다.
• 보이는 부분에 대한 설정을 스스로 직접한다.

ViewModel

• View로 부터 전달받는 요청을 처리할 로직을 담고 있으며, Model에 변화가 생기면 ViewModel이 View에 notification을 보낸다. (데이터의 변화를 View가 알아챌 수 있도록 하는 것)
• ViewModel은 View와 Model 사이의 중개자 역할을 하며, Presentation Logic을 처리하는 역할

Presentation Logic이란?

ViewModel은 Model의 클래스의 메서드를 호출하여 Model과 상호작용한다. ViewModel은 Model의 데이터를 가져오고, View가 쉽게 사용할 수 있는 형태로 가공하여 제공한다.
ex) View가 데이터를 더 쉽게 처리할 수 있도록 데이터 형식을 다시 지정 (formatting)

 

 

 

동작 흐름

1. View에 들어온 Event를 ViewModel에게 알려주면 ViewModel은 Model을 업데이트 시킨다.

2. Model이 변화하면 ViewModel에 알려지고, ViewModel과 바인딩되어있는 View가 업데이트된다.

 

 

MVC와 차이점

• MVVM의 View는 ViewModel을 알고 있으며, 소유한다. 그리고 ViewModel은 Model만을 알고 있도록 구현한다. (Model은 MVC와 크게 다르지 않다.)
• MVVM의 View는 ViewModel과의 데이터 바인딩을 통해 스스로 데이터를 보여준다.(데이터를 View에 보이게 하기 위한 설정 책임을 View 스스로가 가진다.)
• MVC에서는 View에서 사용자의 action을 Controller에 알릴 때 Delegate 패턴 또는 Target-Action을 썼지만, MVVM의 View가 ViewModel을 알고 있으므로 필요할 때 ViewModel의 메서드를 호출하는 방식으로 구현이 가능하다.
• MVC에서는 유저 상호작용이 일어났음을 View -> Controller로 알리고 그에 따라 어떤 행동을 할지는 모두 Controller가 정했다면, MVVM의 ViewModel은 로직만 가지고 있고, 어떤 행동을 할지는 View가 정한다.
• 데이터가 변경되었음을 알리는 방향은 Model -> Controller, ViewModel로 동일하다. 하지만 MVC에서는 그 사실에 따라 View를 어떻게 다시 그릴지는 Controller가 전한 반면, MVVM에서 ViewModel은 바로 View에게 그 소식을 전달하는 역할을 하고 View가 알아서 데이터를 받아와 알아서 다시 그린다.

 

 

 

MVVM 장단점

장점

• 책임 분배 : MVVM의 ViewModel은 MVC의 Controller의 부담을 덜어준다. (수행해야 할 역할이 더 적다)
• 테스트의 용이성 : ViewModel과 View간의 의존성이 없기 때문에 테스트에 용이하다.

 

단점

• 바인딩같은 작업을 해야하기 때문에 간단한 프로젝트에서 하기엔 MVVM이 과하다.
• 바인딩을 도와주는 라이브러리를 함께 사용하지 않으면, 많은 기반 코드를 작성해야 한다.
• 바인딩 등 여러가지 부분에 대해 정해진 답이 없다보니 사람마다 MVVM을 구현하는 방식이 다 다르다. 때문에 MVVM을 처음 접하는 입장에서는 패턴을 어떻게 구현해야 할지 막막하다. (이것 저것 적용해보면서 본인만의 스타일을 만들어야 한다.)

 

 

[참고 : https://velog.io/@ictechgy/MVVM-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4]