[220831] TIL

[Taehyeon-Kim]

패턴을 아는 것은 그렇게 중요한 일이 아니다.

• '무조건 이렇게 틀을 만들어놓고 짜야 돼!' 이런 것이 아니다.
• 어느 것이 더 좋고 나쁘고 이런 것은 없다.

MVC

• Controller = 일반적으로 우리가 생각하는 ViewController, Model과 View는 Controller에 의존할 수 밖에 없다.
• View = Controller's minions, Label · Button 등
• Model = Realm Data Schema, Custom Class, Service Model - 화면과 상관이 없는 것, 본질적인 데이터를 다루는 것

3가지를 완전히 분리하는 것은 어렵다.

Controller, Model, View

• Model에게 말을 걸 수 있다. 데이터를 달라고.
• Controller에서는 항상 Model에 접근하는 코드를 사용했다.

  var list: [BoxOffice] = []

• View와는 Outlet 등의 방식으로 연결되어 있다. (왜냐하면 뷰는 어느 컨트롤러에 속해있는지 모르기 때문!)
• Model과 View는 직접적으로 소통하지 않는다. Controller에서 둘을 연결해주는 역할을 담당한다.
• View는 Action을 통해 Controller에게 요청한다. 그게 어렵다면 Protocol(should, will, did)을 이용하고는 한다.

MVC의 문제점

• 컨트롤러가 하는 일이 너무 많아진다. 가지는 책임과 역할이 너무 많다.
• 사용자 눈에 보이지 않는 로직, 데이터를 한 번 가공 : 비즈니스 로직

MVVM

• 뷰 컨트롤러가 담당하고 있는 기능 중 일부를 분리해보자.
• 비즈니스 로직을 담당하는 녀석을 ViewModel이라는 이름으로 분리해보자.

Model

• UI와 독립적
• 데이터 + 로직
• The Truth

View

• Model의 정보를 반영
• Label, Button 등
• View는 ViewModel에게 신호만 줌

ViewModel

• 기존에 뷰에 모델(데이터를 가지고 있는 것)에 대한 정보를 반영하는 것을 Controller가 했었음.
• 이 역할을 ViewModel이 하게 된 것임
• 그래서 ViewModel은 Model을 참조하고 있음
• 중계자의 역할을 함(Interperter, GateKeeper)

[Taehyeon-Kim]

왜 ViewModel이 등장하게 되었는가? 에 대한 이해가 중요함