[iOS] MVVM 패턴 알아보기 (vs MVC 패턴) (1)

이전까지는 프로젝트를 진행할 때 디자인 패턴이나 아키텍쳐에 크게 신경을 쓰지 않고 있었습니다.

그러나 이번에 동아리에서 앱개발을 진행하면서 개인앱보다 비대해진 앱개발을 진행하다보니 자연스럽게 

좀 더 효과적인 코드관리등을 생각하게 되었고 그렇게 디자인 패턴에대해 조사를 해보게 되었습니다.

 

디자인패턴에 대해 조사를 하다보니, 상당히 많은 디자인 패턴이 있더라구요?

그래도 그 중에서, 가장 대중적으로(?) 공부가 되고있는 MVVM패턴에 대해 조금 공부를 해 보았습니다.

(사실, 현재 앱이 MVC로 제작이 되어있는데 코드를 리팩토링 하려하다보니 자료가 더 많은 디자인 패턴을 공부하게 되었어요 ㅎ,,,)

 

아직 공부가 완전히 된 것은 아니지만, 제가 자료들을 읽어보고 찾아본 내용으로 정리를 해볼까 합니다.

기본적으로 목표는, 실제 MVC로 제작한 제 어플을 MVVM으로 바꾸는 것을 목표로 

최대한 이해하기 쉽게 설명을 해 보도록 하겠습니다..!!

 

※ 아직 제 식견이 많이 좁기 때문에, 글 작성시 잘못 된 내용이 있을 수 있습니다. 

따라서, 잘못된 내용 지적해주시면 감사하겠습니다.!!

 

 

 

---

 

 

자 우선, 본격적으로 MVVM 패턴을 알아보기 전에

앱 개발을 해 보셨다면 자연스럽게 접하게 되는 디자인패턴인 MVC패턴에 대해 먼저 알아보겠습니다.

 

- wiki -
모델-뷰-컨트롤러 (Model - View - Controller, MVC)는 소프트웨어 공학에서 사용되는
소프트웨어 디자인 패턴이다.

 

위의 설명만 보면,

 

"아 ~ 정확히는 모르겠지만, 하나의 디자인 패턴이구나~,,,,,그래서 모델 뷰 컨트롤러가 대체 뭐지,,?"

 

라는 의문이 생길 수 있습니다!

 

모델(Model)이란?

Model은 이름 그대로, iOS 개발자가 사용하려는 Data들의 모임 이라고 생각하면 됩니다.

가령, 우리가 네트워크 통신을 위해 특정URL을 따로 상수로 빼서 처리하는 경우가 있죠??

static let baseURL : String = "기본으로 사용하는 URL/"

이러한, Constant한 변수도 Model에 저장되는 Data의 일종입니다.

 

또, URLSession이나 Alamofire같은 라이브러리를 사용하여 GET 메소드를 호출한다고 생각 해 봅시다. 

이때 우리는 서버에서 받아오는 데이터를 그대로 사용할 수 있나요??

당연히 안됩니다!!

 

서버에서 Data를 받아올 때는 주로 json형식으로 데이터를 받아오게 되는데, 이렇게 받아온 Data는

특정한 모델의 형태로 데이터를 저장해줘야 합니다.

바로 이렇게요!

struct GetSchool : Codable {
    let students : Int
    let classes : Int
    let schoolName : String
}

이렇듯, 서버에서 받은 데이터를 실제로, UI에 적용하기 위한 form의 일종이라고 할 수도 있겠네요! 

 

그렇기 때문에, Model은 UI와는 직접적으로 연결되지 않기 때문에 UI에 Data를 어떤 식으로 보여줘야할 지

고민 할 필요가 없습니다.

 

예를 들어서, 위에서 작성한 코드를 보면 

GetSchool라는 Data형태(구조체)에 학생수에 대한 Int값을 저장하는건 가능하지만 

여기서 저장된 학생수 를, 어떻게 실제 Label에 저장 할 지는 고민하지 않아도 됩니다!

 

실제 라벨에 데이터를 저장하는

label.text = "\(sch.students)"

와 같은 코드는 Model에 정의하지 않는다는 의미입니다!

 

이 밖에도 Model에는 몇가지 기능이 더 있는데, 한번에 요약하면

 

1. 데이터로 사용하는 구조체: 위에서 예시로 GetSchool 구조체를 의미합니다.

2. 네트워크 로직: 서버와 통신을 하고 결과를 주고받는 로직을 의미합니다.

3. Persistance 로직: 음..흔히 알고있는 Core Data나 Realm에서 사용하는 영구데이터 저장을 생각하면 됩니다.

(persistance == CoreData or Real 이건 아니에요! )

4. 데이터 파싱 로직: 서버로부터 받은 데이터를, 실제 UI에 표현하기위한 데이터형으로 json을 파싱하는 로직을 말합니다.

5. Manager 객체: 싱글턴 객체와 비슷하게, 구조체를 어디서든 접근하게 만들어주는 Manager를 의미합니다. 

6. Util, Extension, Constant:  color를 rgb로 계산해서 따로 특정 변수로 저장하거나, String을 확장하여 함수를 만드는 등과 같은 커스텀한 로직들을 저장 하는 것도 Model에 포함됩니다.

 

 

뷰(View)란?

이름에서도 알 수 있지만 말 그대로 실제 유저에게 보여주는 화면 그 자체

즉, UI를 의미합니다!

 

그렇기 때문에,

1) 우리가 가지고 있는 Data를 UI로 유저들에게 보여주기위한 로직

2) UI를 구성하는 Layout과 같은 로직

등을 가지고 있게 됩니다.

 

View는 뒤에 나올 Controller에서 완성이 된 Data를 받아서 UI로 표현하게 될텐데, 

그렇다고 무조건  View에서 따로 Data를 만들면 안되는 것은 아닙니다.

 

예를 들면, 어떤 버튼을 on/off하는 로직이 있다면 

특정 상태를 저장하는 변수라는 Data가 필요하겠죠?

이러한 Data는 View에서 만들어도 괜찮습니다!

 

그리고 개발을 하다보면, 

 

" 뷰의 재사용성이 중요하다~ "

 

라는 말을 많이 들어보셨을 겁니다.

위에서 말 한 [어떤 버튼]이 과연 하나의 화면에서만 사용이 될까요??

 

여러 화면에서 공통적으로 사용이 된다면,

매번 코드를 새로 만들지 말고 필요할 때 마다 불러와서 사용하면 좋지 않을까요??

 

이렇게 쓸데없는 코드의 낭비를 막기 위해서라도, 뷰의 재사용성이 중요하다고 하는 겁니다.

비단 뷰 뿐만이 아니라 여러 반복적인 로직들도 잘 정리해놓고 해당 함수를 불러오기만 하면

코드의 양이 획기적으로 줄어들고 코드의 가독성도 많이 좋아질겁니다.

 

 

컨트롤러(Controller)란?

Controller는 View와 Model의 징검다리 역할을 합니다.

쉽게 말해서, Model에 있는 데이터를 실제 View에서 다룰 수 있도록 만들어준다고 생각하면 됩니다.

(그리고 나중에 작성 할 MVVM의 요소인 ViewModel과 거의 비슷한 역할을 한다고 먼저 생각합시다!)

 

Controller는  Model에서 가져온 데이터를 View에 전달하고, View는 화면을 refresh하게 됩니다.

이렇게 유기적으로 연결되어서 동작하도록 하는 역할을 Controller가 하게 됩니다!

 

당연히 역으로, View에서 받은 어떠한 액션으로 새로운 Data를 받으면 이를 바탕으로 로직을 통해

Model정보를 업데이트 하기도 합니다!

 

이처럼 Controller는 각 뷰에 맞는 로직을 가지고 있어야하기 때문에 재사용성이 View에 비해 많이 부족합니다.

 

 

 

자, 이렇게 MVC각 요소에 대해 이야기 해 봤으니

이제 본격적으로 MVC 패턴에 대해 알아보겠습니다!

 

---

 

Tranitional MVC 패턴

우선, iOS에서의 MVC패턴은 Apple-MVC 와 일반 MVC 2가지로 분류가 됩니다.

 

Traditional MVC Pattern

위의 사진을 보면, View는 상태가 고정적이지 않습니다!

무슨 의미인가 싶죠??

 

사진에서는 Model의 상태가 바뀔 때 마다, Controller에 의해 View가 새롭게 refresh되는 걸 볼 수 있습니다.

이를 통해 View의 상태가 고정적이지 않다는 것을 알 수 있겠죠???

[어떤 어플에서 page가 바뀌는 버튼을 눌렀을 때, 전체적인 View가 바뀌면서 새로운 창으로 넘어간다]

와 같은 동작을 예시로 들 수 있겠네요!

 

얼핏 보면 논리적으로는 iOS에 적용하기에 이상이 없어보이죠??

하지만, 이 Traditional MVC 패턴에는 iOS에 바로 적용하기에는 구조적인 문제점이 있습니다!

 

 

Model - View  - Controller 이 3개의 Entity들이
서로 서로 너무 밀접하게 연관이 지어져있고, 각 Entity가 서로의 상태를 직접적으로 관찰이 가능하다

 

"이게 대체 무슨말이야...?" 라는 생각이 들죠??

쉽게 말하자면, 서로가 독립적이지 못하다는 뜻 입니다!

 

우리가 실제 개발을 진행하다 보면, 특정 함수만 시험 해 보는 경우가 있고 혹은 특정 View만 Unit단위로

테스트를 해야하는 경우가 발생을 합니다.

하지만, 만약 위의 구조처럼 각 Entity들이 서로 밀접한 관계로 이루어져 있으면

정말 독립적인 단위테스트가 가능할까요??

 

아닙니다. 결국, 하나를 건드리면 3개를 모두 건드리게 되는 대참사(?)가 발생하는 것이죠!

 

apple이 의도하는 최신 iOS 개발방향과는 많이 다르기 때문에, 변형된 디자인 패턴이 등장하게 됩니다....

 

 

Cocoa MVC 패턴

Cocoa MVC Pattern

기존의 MVC에서 개선된 Cocoa MVC패턴입니다.

그림에서 볼 수 있듯이, Controller는 View와 Model사이에서 중재자 역할을 합니다.

 

우리가 아는 중재자의 의미란 무엇인가요??

바로, 서로가 만나지 못하지만 서로의 의견을 조율해주는 역할

바로 이것이 이 Cocoa MVC 패턴의 주요한 특징입니다.

 

Traditional MVC 에서는 View와 Model이 서로 직접적으로 정보를 주고 받았지만, 

Cocoa MVC에서는 Controller라는 중재자를 통해 간접적으로 정보를 주고 받게 됩니다.

 

그렇기 때문에, View와 Model은 서로의 상태를 모르는 서로에게 독립적인 존재가 됩니다.

 

우리가 앞에서 Controller는 재사용성이 낮다 라고 했던거 기억 하시나요??

 

그렇다면 이왕 재사용성이 낮은거, Model에 있는 까다로운 비지니스 로직을

Controller에 다 넣어버리자~~

 

이것이 이 Cocoa MVC의 중요한 특징입니다.

 

자, 얼핏보면 상당히 직관적이고 좋은 것 같죠? 

하지만 apple은 불만이 많았어요,,,,,,

 

사람들은 흔히들, 

 

MVC 패턴은 Massive ViewController를 가지고 있는 패턴이야~

 

라고 말 하고는 합니다.

게다가, ViewController를 참조(이미 만들어진 VC를 가져다가 사용하는 것)은 이미 iOS 개발자에게는

중요한 Topic이었습니다.

 

그러다보니 당연히, Apple은 더 나은 개선책을 가져왔겠죠???

 

 

Apple's MVC 패턴

사실 위의 사진은 Realistic Cocoa MVC 패턴인데 흔히 Apple's MVC패턴이라고 불리우고 있습니다.

 

앞에서 말 했듯이, Cocoa MVC패턴에서 ViewContoller들이 Massive한 것은 어쩔 수 없이 받아들여졌습니다.

그 이유 중 하나가 이런 ViewController들은 View들의 life cycle에 상당히 많이 관여하고 있기 때문이거든요...

 

그렇기 때문에 MVC패턴은 단위테스트를 하기에는 썩 적합하지 않은 패턴이라고 할 수 있겠네요...

하지만 아무래도, 다양한 로직을 각 각 분할하지 않고

뭉탱이로(?) 모아놓다 보니, 빠르게 개발을 진행할 수 있다는 장점도 있답니다 ~!

 

사실 이 MVC패턴이 이런 Massive함도 없었다면, 제가 공부하는 MVVM이나 여타 다른 디자인 패턴이

나오지도 않았겠죠,,,?

 

아무튼! 

이렇게 간단하게(?) MVC모델에 대해 알아보았는데, 이해가 잘 되셨으면 좋겠네요,,,

아직 학생이라 공부하면서 작성한 부족함이 많은 글이지만, 

부족하거나 잘못된 부분은 지적해주시면 감사히 배우도록 하겠습니다!

 

이상으로 글을 마치고, 다음엔 MVVM에 대한 글을 써 보도록 할게요!

 

 

 

 

 

 

 

 

 

참고자료 : 

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

https://developer.apple.com/library/archive/documentation/General/Conceptual/CocoaEncyclopedia/Model-View-Controller/Model-View-Controller.html