Understanding MVC & MVVM pattern

hk k·2022년 8월 11일

목록 보기

2/3

1. MVC pattern

MVC 패턴이란?

MVC 패턴이란 애플에서 기본적으로 지원하는 디자인 패턴으로
Model + View + Controller 구조의 디자인 패턴으로 줄여서 MVC 패턴이라고 한다.

Model은 앱의 데이터와 데이터를 관리하는 로직을 가지고 있다. 직접적으로 UI와 연결되지는 않으며 받아온 데이터를 그에 맞춰 저장할 형태를 만드는 것이 더 중요하다. Model에는 대부분 데이터로 사용하는 구조체, 네트워크를 요청하고 그 결과를 받아오는 네트워크 로직, 메모리에 저장되는 데이터를 로드하고 세이브하는 persistance 로직, 데이터 파싱 로직 등이 포함된다.
View는 흔히 말하는 UI로, 사용자에게 데이터를 보여주고, 어떻게 보여줄지 화면을 구성하는 코드들이 포함되어있다. 기본적으로 View는 Controller로부터 데이터를 받아서 화면에 보여주는 역할을 하나 사용자와 직접 상호작용하기 때문에 사용자 액션을 Controller로 전달하는 역할도 한다.
View를 작성할 때는 재사용성이 강조되며 화면에 들어가는 여러 요소들을 어떻게 잘 나누어서 앱 전반에서 재활용할 수 있도록 할지가 중요하다. View에는 주로 UIView를 상속해 만들어진 subclass, core animation, core graphics 등이 포함된다.
Controller는 앱의 핵심 로직을 담고 있는 계층으로 Model과 View를 이어주는 다리 역할을 한다. View에서 보여주기 위한 데이터를 이 Controller가 보내주면서 View를 refresh하고, 그 데이터를 Model로부터 가져오는 기능을 한다. 그리고 View로부터 사용자 액션에 대한 정보를 받고, 그 정보를 바탕으로 해당된 로직을 실행하고 Model의 정보를 업데이트한다. Controller는 해당 View마다 하나씩 붙어서 그 View에 맞는 로직을 포함하고 있기 때문에, 재사용성은 View보다 떨어진다.

MVC 패턴 동작 원리

Controller는 Model과 View에게 직접 지시를 할 수 있지만 Model과 View는 Controller에 직접적으로 알릴 수 없다. Model의 데이터가 변경된 것을 알리거나, View에서 사용자 액션이 발생했을 때 Controller에게 알리는 방법은 무엇일까?

View to Controller

먼저 View의 경우

Controller는 View에서 발생할 수 있는 action에 대한 target을 만들어두고 View에서 유저의 액션이 발생할 경우 Controller에 있는 target이 이를 받아들이고 작업을 수행
한다.
또한 View는 delegate 패턴의 delegate와 datasource를 이용하여 Controller에게 어떤 작업을 수행해야하는지 알리기도 한다.

Model to Controller

Model의 경우에는

Model은 Observer 패턴의 Notification과 KVO를 통해 Controller에게 알린다. Controller는 Model에 있는 프로퍼티에 Key-Value Observing을 이용해 그 프로퍼티의 변화를 감지할 수 있고, 그에 따라 새로운 데이터를 받아올 수 있다. 혹은 Notification을 이용해 뭔가 변화했다는 신호를 보내두면, 나중에 Controller가 그 아릶을 보고 다시 Model에 접근해 새 데이터를 받아올 수 있다.

MVC 패턴의 장단점

장점

애플에서 기본적으로 지원하고 있는 패턴이기 때문에 쉽게 접근할 수 있다.
많은 개발자들에게 친숙한 패턴이기 때문에 개발자들이 쉽게 유지 및 보수할 수 있다.
개발 속도가 빠르기 때문에 규모가 작은 프로젝트에서 사용하기 좋다.

단점

View와 Controller가 밀접하게 연결되어 있어 분리하기 어렵고 재사용성이 떨어지며 유닛 테스트를 진행하기 힘들다.
대부분의 코드가 Controller에 밀집될 수 있다.
delegate나 datasource 관리, 네트워크 요청, DB에 데이터 요청 등 많은 코드가 Controller에 작성되면 Controller의 크기는 비대해지고 내부 구조는 복잡해지게 된다.
이러한 이유로 프로젝트 규모가 커질수록 유지보수가 하기 힘들어진다.

2. MVVM pattern

MVVM 패턴이란?

MVVM 패턴 또한 MVC와 마찬가지로 앱 개발에 주로 사용되는 디자인 패턴으로 MVC의 Controller대신에 ViewModel을 가지고 있다. ViewModel또한 Controller처럼 View와 Model의 중간 계층 역할을 하고 있다.
Model은 MVC의 Model과 마찬가지로 데이터와 관련된 코드를 담고 있다. 데이터를 담아두기 위한 구제초와 네트워크 로직, JSON 파싱 코드 등을 담고 있다. 또한 Model은 View, ViewModel 계층을 전혀 신경쓰지 않아도 된다. 데이터를 어떻게 가지고 있을지만 고려하면 된다.
View는 앱의 UI에 대한 코드를 담고 있는 계층이다. 각 컴포넌트에 대한 정보를 담고, 어느 위치에 어떻게 배치될지 작성되어있다. 디자인적인 요소 뿐만 아니라, ViewModel로부터 데이터를 가져와 어떻게 배치할지, 특정 상황에 따라 ViewModel의 어떤 메서드를 이용할지에 대해서도 가지고 있다.
ViewModel은 앱의 핵심적인 비즈니스 로직을 담고 있는 코드의 계층이다. MVC 패턴의 Controller와 비슷한 역할을 하고 있다. View와 Model의 사이에서 View의 요청에 따라 로직을 실행하고, Model의 변화에 따라 View를 refresh 하는 등 유사한 점이 많다.
Model에 변화가 생기면 View에게 notification을 보내주는 역할을 한다. 또한 View로부터 전달받는 요청을 해결할 비즈니스 로직들을 담고 있다. ViewModel은 UI 관련 코드로부터 완전히 분리되어있고, 따라서 ViewModel 파일에는 SwiftUI같은 UI 프레임워크를 import하지 않는다.

MVVM 패턴과 MVC 패턴의 차이는?

UIKit에서는 ViewController가 주인공이고, SwiftUI에서는 View가 주인공이다. UIKit의 MVC에서는 ViewController가 거의 모든 역할을 하고 있었다. ViewController 단위로 하나의 화면이 구성되고 Controller는 View 계층, Model 계층을 모두 소유하고 있으며, Model의 notification도, View가 사용자 액션을 전달하는 방식도 모두 delegation 방식을 통해 ViewController가 떠맡고 있었다.

하지만 SwiftUI의 MVVM에서는 View가 ViewModel을 소유하고, ViewModel이 Model을 소유하는 방식이다. Controller 단위로 화면이 구성되는 것이 아닌, 해당 화면을 주도하는 것은 View이다. 각 View가 필요한 비즈니스 로직들을 가져와 사용하는 구조이다. 따라서 View와 Model을 모두 알고 있었어야 하는 Controller와 달리 ViewModel은 View에 대해서는 알고 있을 필요가 없다. ViewModel은 비즈니스 로직만 가지고 있도록 깔끔하게 분리된 계층이기 때문에 ViewController만큼이나 코드의 길이가 길어질 이유가 없다. View 입장에서는 필요한 비즈니스 로직을 담은 ViewModel을 해당 화면의 니즈에 따라 골라서 사용하기만 하면 된다.

MVVM 계층의 연결

MVVM의 핵심은 Data Binding, 데이터 바인딩이다. 데이터 바인딩은 데이터를 제공하는 자와 그 데이터를 사용하는 자를 연결시켜 동기화되도록 하는 방식이다. View는 ViewModel을 소유하고 있으며 이 ViewModel은 View에 의해 Observed 되고 있다. ViewModel의 특정 프로퍼티(Published 되고 있는 프로퍼티)에 변화가 생기면 그 데이터의 변화를 유저들에게 보여주기 위해 View가 다시 그려진다. MVC에서는 사용자 액션이 일어났음을 View -> Controller로 알리고 그에 따라 어떤 행동을 할지는 모두 Controller가 정했다면, MVVM의 ViewModel은 로직만 가지고 있고, 어떤 행동을 할지는 View가 정한다. 데이터가 변경되었음을 알리는 방향은 Model -> Controller, ViewModel로 동일하다. 하지만 MVC에서는 그 사실에 따라 View를 어떻게 다시 그릴지 Controller가 전한 반면, MVVM에서는 ViewModel은 바로 View에게 그 소식을 전달하는 역할을 하고 View가 알아서 데이터를 받아와 알아서 다시 그린다.