[iOS] Architecture - MVC, MVVM, MVP

0. Model, View

• Model : 내 앱에 있는 모든 data와 logic 이 있는 부분.
  카드 게임에서 카드의 구조, 카드덱(몇 장 있는지), 카드를 골랐을 때 어떤 일이 벌어지는지, 또 카드를 뒤집어서 어떻게 점수를 따는지 같은 부분이다.

class CardGame {
    var cards: [Card]()
    var indexOfOneAndOnlyFaceUpCard: Int?

    func choose(card: Card) {
        // 카드를 눌렀을 때 수행하는 동작
        card.isFaceUp = !card.isFaceUp
    }
}

struct Card {
    var isFaceUp = false
    var isMatched = false
    var identifier: Int
}

• View : 화면에 보이는 UI, 사용자는 View만 본다.
  버튼처럼 화면에 보여지는 부분이다.

• data는 Model 에서 View 쪽으로 흘러간다. (View는 정보를 받아서 보여주는 역할만 할 뿐!) 그런데 View는 Model에 바로 영향을 끼칠 수 없기 때문에,

• Model을 View에 해석해주고, User Input 을 Model에 해석해주는 일을 MVC에서는 Controller가, MVVM 에서는 View Model, MVP에서는 Presenter가 담당하게 된다.

1. MVC

C:V = 1:n

동작

1. 사용자 입력이 Controller에 들어온다.
2. Controller는 입력을 해석하여 Model을 업데이트 한다.
3. Controller는 Model 업데이트 결과를 보여줄 View를 선택한다. (직접 업데이트를 하진 않음.)
4. View는 바뀐 Model을 이용해서 UI를 Update 한다.

 

예시

1. 사용자가 카드(뒷면이 보이는)를 누른다.
2. Controller 가 model 의 choose 함수를 실행한다.
   (카드의 isFaceUp이 true 로 바뀐다.)
3. Controller는 뒤집혀야 할(Model의 업데이트 결과를 보여줄) 카드를 선택한다.
4. View(Card)는 (isFaceUp 이 true가 된 Model을 이용하여) Card의 앞면을 보여준다.

 

장점

• iOS UIKit 방식에서 기본으로 제공하는 구조이고, 단순해서 쉽게 구현할 수 있다. 실제로 나도 이 구조를 이용했다.

단점

• View를 update 하기 위해서 Model을 이용해야 하므로 Model과 View 의 의존성이 높다.
• Controller 안에 View 가 있어서, View를 변경하려면 Controller 를 변경해야 한다.
• 규모가 커지면 아주 복잡해져서 유지보수가 어렵다.
• 최근에 iOS 에서 deprecated 되었다...

 

in iOS

MVC의 일반적인 구조는 위와 같지만, 스탠포드 강의에서는 iOS 에서 사용하는 여러 방법들이 적용된 방식으로 설명을 해준다.

1. Controller 는 Model, View에 직접적으로 말을 걸 수 있다. (View 에 말을 걸 때는 outlet 을 이용한다.)

2. Model과 View는 서로 직접적으로 말할 수 없다. 독립적이다.

-> 여기가 보통의 MVC와는 다르다.

3. View 는 Controller에게 말할 수 있지만, Controller가 뭔지 모른다.
   • 그래서 target-action 방식을 이용하여 말할 수 있다.
   • View가 Controller와 동기화 해야하는 경우에는 delegate를 이용해서 (ex. UITableViewDelegate) Controller 에게 하고 싶은 동작을 위임(떠넘기기) 할 수 있다. delegate는 protocol로 설정 가능.
   • 또, View는 data를 instance로 가지고 있는 것이 아니기 때문에 Controller 를 data source로 사용한다.

4. Controller는 View와 사용자의 상호작용을 Model에 해석해준다.

5. Model 은 UI에 독립적이기 때문에, Controller 에게 직접 말을 걸 수 없다.
   • Notification & KVO 를 이용해서 라디오처럼 Model이 바뀌었다고 방송을 하면,
   • Controller 가 듣고 있다가 바뀐 부분을 View 에 전달해서 UI가 수정된다.

6. 하나의 MVC는 단 하나의 화면만을 제어한다.
   • 앱이 커지면 당연히 여러 MVC 가 존재하기 때문에, Controller 는 다른 MVC 구조의 Controller를 본인의 View로 생각하고 말을 건다.

• VC에 View 와 model property가 모두 들어가게 된다.
• Controller와 View를 떼어내서 보기가 어렵다.

2. MVP

MVC에서 파생. Presenter는 뜻 그대로 진행자의 역할을 한다.

P:V = 1:1

작동

1. User input 이 View로 전달된다.

2. Presenter는 View에게서 입력을 전달받아
3. 해당 입력에 맞는 Model을 업데이트 한다.

4. Model은 업데이트 된 데이터를 Presenter에 응답한다.
5. Presentor 가 데이터를 View에 응답한다.

6. View는 UI를 업데이트 한다.

 

장점

• Model과 View가 독립적.

단점

• Presenter와 View 사이의 의존성을 가짐.

 

in iOS

1. model(struct) 을 만든다.

2. Service class 가 Data Provider 의 역할을 하게 한다.
3. Presenter가 Data Provider(Model을 실상황에 맞게 구현한 것)과 View 의 프로퍼티를 가지고,
4. View Controller 에는 View에 관련된 것만 구현을 한다.
5. View에서는 protocol, delegate 를 이용하여 사용자 입력이 들어왔을 때, Presentor에 있는 함수가 실행되도록 한다.

 

iOS MVP 예제
iOS Swift : MVP Architecture

3. MVVM

VM:V = 1:n

ViewModel 은 View 에 보여주기 위해서 만든 Model. View에 보여주기 위한 Data 처리를 수행한다.

작동

1. User input 이 View로 전달된다.

2. View가 입력을 확인 후, ViewModel로 전달한다.

3. ViewModel이 Model에 데이터 요청

4. Model은 ViewModel에 데이터 응답.

5. ViewModel은 데이터를 가공하고 저장한다. (View에 줄 수 있는 형태로)

6. View는 VM에 있는 가공된 데이터를 이용해서 UI를 업데이트 한다.

 

장점

• Model과 View 사이의 의존성이 없다.
• ViewModel의 값이 변하면 View가 자동으로 업데이트 된다. (Data Binding)

단점

• ViewModel 의 설계가 어렵다. 스탠포드에서 한 카드게임처럼 명확한 ViewModel의 개념이 서는 경우를 제외하면 어떻게 설계해야할지 모르겠다

 

in iOS

1. Model -> View 로 데이터가 흐르게 되는데,

2. 둘 사이의 번역가 역할을 ViewModel 이 수행해준다.
   View를 Model 에 묶어주는 역할.

3. Model이 VM에게 데이터의 변화를 알려주면, VM이 데이터를 해석해서뭔가 바뀌었다고 방송하게 된다. (@Published 키워드 사용)
   MVC에서 Model 이 변화를 Notification & KVO로 방송하는 것과 비슷하다고 느꼈다

4. 그러면 View는 그것을 Observe(관찰) 하고 있다가 변화를 감지해서 Model 의 현 상태로 UI를 다시 그린다. (@ObservedObject, @Binding 같은 키워드 사용)

5. View로 User 입력이 들어오게 되면, View는 VM에 있는 intent function을 부른다.

6. VM은 model을 수정하고, model이 바뀌었기 때문에 1~4 의 과정이 다시 일어나게 된다.

자료 출처

MVC : Stanford - CS193p 2017-2018 fall
MVVM : Stanford - CS193p 2020 spring
나머지는 내가 만듬

참고

1. [Design Pattern] MVC, MVP, MVVM 패턴이란?
2. MVC, MVP, MVVM, MVI
3. [디자인패턴]MVC , MVP,MVVM 이란 무엇인가?
4. [디자인패턴] MVC, MVP, MVVM 비교
5. [ Design Pattern 04 ] MVC, MVP, MVVM 의 3가지 패턴의 차이
6. MVC, MVVM, MVP, VIPER, VIP를 알아봅시다.