[iOS] MVC 란? (feat. Cocoa MVC)

1차 수정: 21.07.26

2차 수정: 21.08.05

 

애플 아카이브 문서를 중심으로 작성하였습니다.

 

 

안녕하세요🐶

 

이번 시간에는 iOS 개발 입문 시기에

거의 필연적으로 사용하는

아키텍처 패턴인 Model-view-controller (MVC) 패턴의 기본 개념을 알아보고,

애플에서 제시하는 Cocoa MVC 에 대해서 다뤄보려고 합니다.

 

그럼 시작해볼게요!!!🔥

 

이 글에서 다루는 것:

 

MVC의 기본 개념

Cocoa MVC란?

 Model, View, View controller 의 역할

Cocoa MVC의 장점 과 단점

---

 

우선,  MVC 의 기본 개념

이 패턴은 User Interface 를 개발할 때 주로 사용되는 패턴으로,

 

1. 사용자로부터 정보를 입력받는 과정

2. 내부적으로 정보를 처리하고 표현하는 과정

3. 처리된 정보를 사용자에게 보여주는 과정

 

총 3가지의 과정을 3가지 역할로 분리하기위해 개발된 것입니다.

 

데스트탑의 GUI 에서 전통적으로 많이 사용되어 왔으며, 웹 앱을 설계하는대에 자주 사용하는 유명한 패턴이 되었습니다.

 

https://en.wikipedia.org/wiki/Model–view–controller

 

여기까지가 위키 백과의 내용인데요.

 

iOS를 개발하는데 필요한 Cocoa Touch 프레임워크가 MVC 를 기반으로 설계되어있습니다.

 

사실 애플에서 제시하는 MVC 의 개념은 조금 다릅니다!!!

 

이것을 Cocoa MVC 로 구분하여 부르기도 합니다.

 

혹시 Cocoa 에 대해서 잘 모르신다면

>>> [iOS] Cocoa (touch) 란? <<<

---

 

Cocoa MVC 란?

 

Cocoa MVC 패턴은

앱 내의 모든 오브젝트가 세 가지의 역할 중 하나를 가지게 합니다.

 

세 가지의 역할은 각각 Model, View, Contorller 입니다.

 

이 패턴은:

 

앱에서 오브젝트가 수행할 역할을 3가지 중 하나로 정의합니다.

3가지 역할은 Model, View, Controller

 

역할이 다른 오브젝트간 의사소통하는 방법을 정의합니다.

 

이 때, 같은 역할을 하는 오브젝트들을 하나의 그룹으로 모아서 레이어  라고 부릅니다.

여러 개의 모델 역할 오브젝트들을 모아서 모델 레이어라고 합니다

 

 

아래 그림은 Cocoa MVC 를 표현한 다이어그램입니다.

간단하게 정리한 Cocoa MVC

 

특징을 간단하게 살펴보자면 🤔

 

View 와 Model 사이의 직접적인 연결점이 없습니다.

둘은 서로에 대해서 모릅니다.

 

View 와  Model  레이어 사이의 정보 교환은 Controller 를 통해서 하고 있습니다.

 

Controller 는 중재자 (meditor) 의 역할을 합니다.

 

또한 위키에서 제시하는 MVC 는 정보의 흐름이 undirectional 합니다.

그런데 Cocoa MVC는 레이어 간에 bi-directional 하게 연결되어 있네요.

 

이제 역할별로 특징을 하나씩 살펴 볼게요!

 

Model Objects

모델 오브젝트는...

 

1. 특정 앱에 한정된 데이터를 캡슐화합니다.

 

2. 데이터를 조작하고 처리하기 위한 로직와 계산을 정의합니다.

 

캡슐화를 한다면 저절로 따라오게 되는 옵션이죠?

캡슐화된 데이터를 조작할수 있는 방법을 제공해주어야 합니다.

 

하나의 모델 오브젝트는 다른 모델 오브젝트와 1 대 1 혹은 1 대 다의 관계를 가집니다.

 

앱의 영속적인 데이터들은 모델 오브젝트로 배정되어야 합니다.

영속적 (persistent) 이라는 의미는 메모리가 아닌 disk, db 등에 담겨 관리된다는 의미입니다.

 

모델 오브젝트들은 특정한 문제를 해결하는 도메인에 필요한 지식이나 전문적 지식을 표현하고 있기 때문에,

다른 비슷한 도메인에서도 재사용될 수 있습니다.

 

또한 모델 오브젝트와 뷰 오브젝트는 서로 어떠한 명시적 연결이 없는 것이 MVC의 이상적인 구조입니다.

 

이 코드는 모델 데이터를 직접 가져와서 cell을 구성하고있다..........이렇게 짜면 안된다는 뜻....

 

뷰 오브젝트가 모델 오브젝트의 데이터를 직접 표현하거나

사용자로 하여금 그것을 수정할 수 있게 할 수 없습니다.

 

< 모델 오브젝트가 다른 오브젝트와 의사소통하는 방법 >

뷰 레이어에서 발생한 사용자 액션은 컨트롤러 오브젝트를 통해서 모델로 전달되며,

모델 오브젝트의 생성이나 업데이트를 일으킵니다.

즉, 전술한대로 뷰 오브젝트는 모델 오브젝트를 직접 생성, 수정하지 않습니다.

 

모델 오브젝트가 변경될때, 그 내용을 컨트롤러 오브젝트에게 전달하고,

다시 컨트롤러 오브젝트는 뷰 오브젝트를 업데이트 해서 화면에 표시합니다.

---

 

View Objects

뷰 오브젝트는 앱에서 사용자가 직접 눈으로 보게 되는 오브젝트 입니다 👁

 

뷰 오브젝트는 스스로 화면에 그리는 방법과 사용자 액션에 반응하는 방법을 알고 있습니다.

 

 

사용자 액션 (이벤트) 에 반응하는 UIResponder 에 대해서 알고 싶다면?

>>> [iOS] 리스폰더 체인이란? <<<

 

 

뷰 오브젝트의 주된 목적은 앱의 모델 오브젝트의 데이터를 화면에 보여주고,

사용자가 그 데이터를 수정할 수 있게 해주는 것입니다.

 

MVC 패턴을 사용한 앱에서는 뷰 오브젝트와 모델 오브젝트가 보통 분리되어 있습니다.

 

프레임워크단에서도 뷰는 모델에 대해서 모르기 때문에 재사용이 가능할 수 있었습니다.

 

Xcode에서 Interface Builder 는 라이브러리에서 수많은 뷰 오브젝트를 제공합니다.

 

< 뷰 오브젝트가 다른 오브젝트와 의사소통하는 방법 >

뷰 오브젝트는 컨트롤러 오브젝트를 통해서 모델 데이터의 변경을 알게 됩니다.

 

뷰 오브젝트는 사용자가 발생시킨 액션 (그리고 액션이 발생시킨 데이터의 변화) 을

컨트롤러 오브젝트를 통해 모델 오브젝트에게 전달합니다.

---

 

Controller Objects

컨트롤러 오브젝트는 중재자 입니다.

 

한 개 이상의 뷰 오브젝트와 한 개 이상의 모델 오브젝트 사이를 중재합니다.

 

앞서 설명하였듯이, 모델과 뷰는 직접 연결되어 있지 않게 하는 것이 MVC 의 이상적인 설계입니다.

 

컨트롤러 오브젝트는 앱의 기초 구성과 조율하는 작업들을 수행하고, 다른 오브젝트들의 생명주기를 관리합니다.

다른 오브젝트 = 모델 오브젝트, 뷰 오브젝트

 

< 컨트롤러 오브젝트가 다른 오브젝트와 의사소통하는 방법 >

컨트롤러 오브젝트는 뷰 오브젝트에서 발생한 사용자 액션을 해석하고,

새로 생성되거나 변경된 데이터를 모델 레이어에 전달합니다.

 

반대로 모델 오브젝트에 변경이 있다면, 컨트롤러 오브젝트는 그 새로운 모델 데이터를 뷰 오브젝트에 전달합니다.

그리고 뷰 오브젝트는 전달받은 데이터를 통해 화면에 새로운 정보를 표시합니다.

---

 

Cocoa MVC 의 '단점' 과 장점

 

실제 Cocoa MVC가 돌아가는 구조

 

현실은 이렇습니다.

 

View 와 Controller 가 분리되어 있는 것이 이상적인 Cocoa MVC 임에도 불구하고,

View 의 생명주기는 Controller 와 밀접하게 관련이 있기 때문에 둘이 분리되어 있다고 보기 힘듭니다.

"tightly coupled"

 

또한 View 와 Model의 역할이 아닌 것은 전부 Controller 가 책임져야하기 때문에,

Controller 의 역할이 방대해지게 됩니다.

 

이런 MVC의 단점을 꼬집어 Massive View Controller (이것도 줄이면 MVC) 라고 부르기도 합니다.

 

모든 역할이 한 클래스에 모여있으면, 유지보수가 매우 힘들어 집니다.

 

소프트웨어공학적 관점에서는 응집도가 떨어지게 되는 것인데,

 

이상적으로 A란 기능은 A 클래스에, B란 기능은 B 클래스가 책임지는

SRP 의 원칙을 준수하는 코드가 유지 보수에 용이합니다.

 

어떤 역할을 수정하려면 어떤 코드를 수정해야하는지 명확해지기 때문입니다.

 

 

또한 Controller 는 UIKit 에 의존하기 때문에, 테스트가 제한적입니다.

 

하나를 예로 들자면,

viewDidLoad(animated: Bool) 과 같은 UIKit 의 메서드를 직접 호출하여 테스트하는 것이 불가능합니다.

 

 

그럼에도 불구하고 Cocoa MVC 는 다음과 같은 장점이 있습니다:

 

우선, 패턴의 구조를 이해하기 쉽기 때문에 입문하는 단계의 개발자들이 쉽게 개발할수 있습니다.

 

또한 빠른 개발이 가능하다는 점입니다.

토이 프로젝트나, 해커톤과 같은 짧은 개발 주기를 가지는 앱을 개발할 때는 이만한 방법이 없습니다.

---

 

마지막으로

 

Cocoa MVC 에서는 컨트롤러 레이어에 해당하는 뷰 컨트롤러의 역할이 너무 비대해지고, Testable 하지 않게 됩니다.

 

이런 단점에 대한 개선으로 MVP 와 MVVM, VIPER 와 같은 대안이 제시되었습니다.

 

궁금하시다면 검색을 통해서 찾아보시면 좋을 것 같습니다.

 

 

끝!

---

참고자료 1: https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

참고자료 2: sungdoo.dev/programming/do-you-know-mvc