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
동작
-
사용자 입력이 Controller에 들어온다.
-
Controller는 입력을 해석하여 Model을 업데이트 한다.
-
Controller는 Model 업데이트 결과를 보여줄 View를 선택한다. (직접 업데이트를 하진 않음.)
-
View는 바뀐 Model을 이용해서 UI를 Update 한다.
예시
-
사용자가 카드(뒷면이 보이는)를 누른다.
-
Controller 가 model 의 choose 함수를 실행한다.
(카드의 isFaceUp이 true 로 바뀐다.) -
Controller는 뒤집혀야 할(Model의 업데이트 결과를 보여줄) 카드를 선택한다.
-
View(Card)는 (isFaceUp 이 true가 된 Model을 이용하여) Card의 앞면을 보여준다.
장점
- iOS UIKit 방식에서 기본으로 제공하는 구조이고, 단순해서 쉽게 구현할 수 있다.
실제로 나도 이 구조를 이용했다.
단점
- View를 update 하기 위해서 Model을 이용해야 하므로 Model과 View 의 의존성이 높다.
- Controller 안에 View 가 있어서, View를 변경하려면 Controller 를 변경해야 한다.
- 규모가 커지면 아주 복잡해져서 유지보수가 어렵다.
- 최근에 iOS 에서 deprecated 되었다...
in iOS
MVC의 일반적인 구조는 위와 같지만, 스탠포드 강의에서는 iOS 에서 사용하는 여러 방법들이 적용된 방식으로 설명을 해준다.
- Controller 는 Model, View에 직접적으로 말을 걸 수 있다. (View 에 말을 걸 때는 outlet 을 이용한다.)
- Model과 View는 서로 직접적으로 말할 수 없다. 독립적이다.
-> 여기가 보통의 MVC와는 다르다.
- View 는 Controller에게 말할 수 있지만, Controller가 뭔지 모른다.
- 그래서 target-action 방식을 이용하여 말할 수 있다.
- View가 Controller와 동기화 해야하는 경우에는 delegate를 이용해서 (ex. UITableViewDelegate) Controller 에게 하고 싶은 동작을 위임(떠넘기기) 할 수 있다. delegate는 protocol로 설정 가능.
- 또, View는 data를 instance로 가지고 있는 것이 아니기 때문에 Controller 를 data source로 사용한다.
- Controller는 View와 사용자의 상호작용을 Model에 해석해준다.
- Model 은 UI에 독립적이기 때문에, Controller 에게 직접 말을 걸 수 없다.
- Notification & KVO 를 이용해서 라디오처럼 Model이 바뀌었다고 방송을 하면,
- Controller 가 듣고 있다가 바뀐 부분을 View 에 전달해서 UI가 수정된다.
- 하나의 MVC는 단 하나의 화면만을 제어한다.
- 앱이 커지면 당연히 여러 MVC 가 존재하기 때문에, Controller 는 다른 MVC 구조의 Controller를 본인의 View로 생각하고 말을 건다.
- VC에 View 와 model property가 모두 들어가게 된다.
- Controller와 View를 떼어내서 보기가 어렵다.
2. MVP
MVC에서 파생. Presenter는 뜻 그대로 진행자의 역할을 한다.
P:V = 1:1
작동
- User input 이 View로 전달된다.
- Presenter는 View에게서 입력을 전달받아
- 해당 입력에 맞는 Model을 업데이트 한다.
- Model은 업데이트 된 데이터를 Presenter에 응답한다.
- Presentor 가 데이터를 View에 응답한다.
- View는 UI를 업데이트 한다.
장점
- Model과 View가 독립적.
단점
- Presenter와 View 사이의 의존성을 가짐.
in iOS
- model(struct) 을 만든다.
-
Service class 가 Data Provider 의 역할을 하게 한다.
-
Presenter가 Data Provider(Model을 실상황에 맞게 구현한 것)과 View 의 프로퍼티를 가지고,
-
View Controller 에는 View에 관련된 것만 구현을 한다.
-
View에서는 protocol, delegate 를 이용하여 사용자 입력이 들어왔을 때, Presentor에 있는 함수가 실행되도록 한다.
iOS MVP 예제
iOS Swift : MVP Architecture
3. MVVM
VM:V = 1:n
ViewModel 은 View 에 보여주기 위해서 만든 Model. View에 보여주기 위한 Data 처리를 수행한다.
작동
- User input 이 View로 전달된다.
- View가 입력을 확인 후, ViewModel로 전달한다.
- ViewModel이 Model에 데이터 요청
- Model은 ViewModel에 데이터 응답.
- ViewModel은 데이터를 가공하고 저장한다. (View에 줄 수 있는 형태로)
- View는 VM에 있는 가공된 데이터를 이용해서 UI를 업데이트 한다.
장점
- Model과 View 사이의 의존성이 없다.
- ViewModel의 값이 변하면 View가 자동으로 업데이트 된다. (Data Binding)
단점
- ViewModel 의 설계가 어렵다.
스탠포드에서 한 카드게임처럼 명확한 ViewModel의 개념이 서는 경우를 제외하면 어떻게 설계해야할지 모르겠다
in iOS
- Model -> View 로 데이터가 흐르게 되는데,
- 둘 사이의 번역가 역할을 ViewModel 이 수행해준다.
View를 Model 에 묶어주는 역할.
- Model이 VM에게 데이터의 변화를 알려주면, VM이 데이터를 해석해서뭔가 바뀌었다고 방송하게 된다. (@Published 키워드 사용)
MVC에서 Model 이 변화를 Notification & KVO로 방송하는 것과 비슷하다고 느꼈다
- 그러면 View는 그것을 Observe(관찰) 하고 있다가 변화를 감지해서 Model 의 현 상태로 UI를 다시 그린다. (@ObservedObject, @Binding 같은 키워드 사용)
- View로 User 입력이 들어오게 되면, View는 VM에 있는 intent function을 부른다.
- VM은 model을 수정하고, model이 바뀌었기 때문에 1~4 의 과정이 다시 일어나게 된다.
자료 출처
MVC : Stanford - CS193p 2017-2018 fall
MVVM : Stanford - CS193p 2020 spring
나머지는 내가 만듬
참고
