MVVM 뽀개기
좋은 아키텍처란?
•
각 객체들의 역할이 분명하며 일이 치중되어 있지 않아야 한다.
•
테스트를 하기에 용이해야 한다.
•
사용성이 편리하며 유지보수 비용이 낮아야 한다.
•
간결한 코드, 그리고 적절한 네이밍 사용 등으로 의사소통이 되는 코드
MVC의 단점
Model과 Controller, 그리고 View 사이 밀접하게 연결되어 있다.
View에서 Controller에 입력을 보내면, Controller는 Model의 상태를 변경시킨다.
→ 거의 모든 로직을 Controller가 담당 → 프로젝트가 커지면 → Controller 코드 양, 질 모두 좋지 못해진다.
→ 그리고 서로 독립성이 없기 때문에, 테스트하기 어렵고 재사용성 또한 떨어진다.
Apple CocoaMVC 패턴
View와 Model 사이의 연관성이 사라졌다
→ View와 Model에서 직접 데이터를 가져오는 것을 Controller가 관리하게 되었다.
→ Model은 독립성이 있지만, View와 Controller는 연관성이 있다.
그렇기 때문에 View와 Controller는 따로 테스트 하는 것이 어렵다.
또한 View와 Model은 Controller가 혼자 관리하기 때문에 코드가 Controller에 치중될 수 있다.
→ 큰 프로젝트에서는 사용하기 부담..
장점
•
개발자들에게 친숙한 패턴, 개발 속도가 빠르다
단점
•
프로젝트의 규모가 커지면 유지보수 하기가 어렵다.
이걸 대체하기 위해 나온 패턴이 바로 → MVVM 패턴
MVVM 패턴
→ Model + View + ViewModel
→ MVC의 View와 Controller 사이의 의존성이 높다는 문제를 해결하기 위해 만들어졌다.
→ 주로 UIKit, SwiftUI에서 사용된다.
Controller의 로직이 ViewModel로 옮겼다고 생각하면 된다.
View
•
View는 단순히 인터페이스를 위한 로직, 생명주기 코드만을 다룬다.
•
MVVM에서 ViewController는 View로 본다.
ViewModel
•
Presentation Logic이 포함되어 있다.
•
ViewModel은 UIKit을 사용하지 않고도, Model과 View 요소를 업데이트 한다 (UI와 독립적으로 테스트를 할 수 있다)
•
Model이 가져온 데이터를 View에 맞게 가공/처리하는 역할을 담당한다.
•
Model이 변경되면 자동으로 View도 변경될 수 있도록 데이터 바인딩을 한다 (데이터 일관성 유지)
데이터 바인딩 : 뷰와 로직이 따로 나뉘어 있지만, 한 쪽이 변하면 다른 한 쪽도 함게 변하는 것이다.
•
View가 ViewModel을 소유한다.
Model
•
데이터를 다루는 부분이다.
•
데이터를 파싱하기 위해 필요한 데이터 구조를 정의한다.
•
초기값과 비즈니스 로직을 관리한다. 이때, 값이 변경 되면 View나 ViewController에게 알린다.
•
ViewModel이 Model을 소유하며, View와는 독립적이다.
→ View와 Controller를 분리하여서 독립성이 생겼다.
→ 그렇게 때문에 각각 독립적으로 테스트를 할 수 있게 되었다.
동작 과정
1.
유저의 Action들은 View를 통해 입력된다.
2.
View에 Action이 들어오면, Command 패턴으로 ViewModel에 Action을 전달한다.
3.
ViewModel은 Model에게 데이터를 요청한다.
4.
Model은 ViewModel에게 요청받은 데이터로 응답한다.
5.
ViewModel은 응답 받은 데이터를 가공해 저장한다.
6.
View는 ViewModel과 Data Binding 하여 화면에 표시한다.
MVC와 MVVM은 어떤 차이일까?
MVC : ViewController
•
MVC에서는 ViewController가 거의 모든 역할을 맡는다.
•
ViewController 단위로 한 화면이 구성된다.
•
Controller는 View 계층, Model 계층을 모두 가지며 Model의 Notification이나 View가 유저의 상호작용을 전달하는 방식도 모두 Delegation 방식을 통해 ViewController가 맡고 있다.
MVVM : View
•
View가 ViewModel을 소유하고, ViewModel이 Model을 소유하는 방식
•
Controller 단위로 화면이 구성되지 않고, 화면을 주도하는 것은 View이다.
•
각 View가 필요한 비즈니스 로직들을 ViewModel에서 가져와서 사용하는 구조이다.
따라서 VIew와 Model을 모두 알고 있었어야 하는 Controller과는 달리, VIewModel은 View에 대해서 알고 있을 필요가 없다.
장점
•
View와 Controller를 분리했기 때문에 테스트하기에 용이하다.
단점
•
설계하기 어렵다.
→ 구조만 정의해놓았을 뿐이고, 규격화 된 것이 없기 때문에 처음에 배우기 어렵고 개발자마다 설계 방식이 다 다르다.
